* Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> [150518 11:19]: > Hi Tony, > > > On May 18, 2015, at 21:14 , Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > * Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> [150518 11:02]: > >> Hi Tony, > >> > >>> On May 18, 2015, at 20:03 , Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >>> > >>> * Robert Nelson <robertcnelson@xxxxxxxxx> [150518 09:51]: > >>>> On Mon, May 18, 2015 at 11:29 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >>>>> * Robert Nelson <robertcnelson@xxxxxxxxx> [150518 09:15]: > >>>>>> On Mon, May 18, 2015 at 10:21 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >>>>>> > >>>>>> All the rev information is in the board's eeprom: > >>>>>> > >>>>>> hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -s 12 -n 4 > >>>>>> > >>>>>> Rev A5B > >>>>>> 0A5B > >>>>>> > >>>>>> Rev C > >>>>>> 000C > >>>>>> > >>>>>> Just another default qwerk to add to Pantelis' bone_capemgr. ;) > >>>>> > >>>>> It seems we should not even instantiate some devices on BBB > >>>>> until the EEPROM is parsed.. So maybe something like this: > >>>>> > >>>>> 1. The problem devices are initially set with status = "disabled" > >>>>> in the dts > >>>>> > >>>>> 2. We set up drivers/*/bbb-eeprom.c that parses the board > >>>>> revision at module_init time, and then flips the selected > >>>>> devices to have status = "enabled" and populates the revision > >>>>> info based on the eeprom and SoC revision passed in pdata. > >>>>> Then those devices get their struct device created and > >>>>> probed, but at a much later time. > >>>>> > >>>>> So rather than trying to init all that early, let's just > >>>>> init them much later when we have the proper I2C driver > >>>>> running? > >>>> > >>>> I see that working just fine. We (beagleboard.org) enforce the eeprom > >>>> data, as all the official images require a proper baseboard eeprom. > >>> > >>> OK > >>> > >>>> We just have to be very careful to limit the scope, otherwise we will > >>>> end up with Pantelis' rejected capebus from the v3.2.x days... > >>> > >>> Naturally I was thinking #2 above would use Pantelis' code for > >>> CONFIG_OF_OVERLAY in mainline. But instead of the earlier patches, > >>> we can make things happen much later on to avoid the detect of > >>> EEPROM early on. > >> > >> Already been taken care of: > >> > >> https://lkml.org/lkml/2015/2/18/258 > >> > >> The patchset works, but it still needs some review eyeballs. > >> There might be a rename to variants or something. > >> > >> You were part of that thread too :) > > > > Right, and what I mean with #2 above is that we can make this all > > into a regular drivers/* device driver with no need for the > > early hacks in your series in arch/arm/mach-omap2/am33xx-dt-quirks.c. > > > > It’s going to be tough. This is touching the pmic that needs to be > initialized early since a whole bunch of drivers depend on it. With the $subject driver we just need to have have RTC driver not probe until the the EEPROM is parsed in the drivers/foo/bbb-eeprom.c driver and the RTC overlay is initialized. Or what's the issue you're talking about? But in any case, let's not merge a copy of the I2C driver into arch/arm/mach-omap2/am33xx-dt-quirks.c. We can do all this with drivers/foo/bbb-eeprom.c that's just a regular device driver. > >> I think it’s best if we go this path instead of twiddling with the > >> status properties manually. Conceptually the idea is similar to > >> the detection of the white/black, with the added joy of revision > >> detection. > > > > If some device drivers depend on the I2C EEPROM, we should not > > create the struct device entry for those until the I2C EEPROM > > driver has parsed the EEPROM. And there's no need to do that > > early, we want to do everything as late as possible. That way > > we have real debug console available in most cases. > > > > FWIW the first patch used an early platform device, but that made things > even more complicated. No need to do any early platform devices, we just need to delay the creation of struct device for the problem drivers. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
