Hi Peter, > On Feb 23, 2015, at 20:39 , Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > > Hi Pantelis, > > On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: >> Hi Tony, >> >>> On Feb 19, 2015, at 20:36 , Tony Lindgren <tony@xxxxxxxxxxx> wrote: >>> >>> * Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [150219 10:32]: >>>>> On Feb 19, 2015, at 20:16 , Tony Lindgren <tony@xxxxxxxxxxx> wrote: >>>>> >>>>> Uhh I don't like the idea of duplicating the i2c-omap.c driver under >>>>> arch/arm.. And in general we should initialize things later rather >>>>> than earlier. >>>>> >>>>> What's stopping doing these quirk checks later on time with just >>>>> a regular device driver, something like drivers/misc/bbone-quirks.c? >>>>> >>>> >>>> We have no choice; we are way early in the boot process, right after >>>> the device tree unflattening step. >>> >>> To me it seems the dt patching part should be done with minimal >>> code before any driver like features.. >>> >> >> The way it’s done right now is with minimal code. Reading the EEPROM >> is required. >> >>>> I’ve toyed with the idea of using early platform devices but the omap-i2c driver >>>> would need some tender love and care to make it work, and I didn’t want to get >>>> bogged down with i2c driver details at this point. >>> >>> ..so how about just parse a kernel cmdline for the quirks to apply >>> based on a version string or similar? That can be easily populated >>> by u-boot or set manually with setenv. >>> >>> That leaves out the need for tinkering with i2c super early in >>> the kernel for revision detection. >>> >> >> You assume there’s going to be a bootloader… > > So does this patch. > Proof of concept, first iteration… The beaglebone is just the prototype stage. >> diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c b/arch/arm/mach-omap2/am33xx-dt-quirks.c > [...] >> + * Note that we rely on the bootloader setting up the muxes >> + * (which is the case for u-boot). > > Regards, > Peter Hurley > Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
