* Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [130107 12:43]: > Hi Tony, > > On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote: > > > * Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [130107 12:29]: > >> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote: > >>> > >>> Well how about split it to an eeprom driver, and Linux generic > >>> device loader parts? > >>> > >> > >> All that's left is the eeprom driver (accessor) and calls to the > >> generic DT overlay constructs. > >> > >> If you caught on the previous patchset about DT overlays it should be > >> clear. > >> > >> So it is split along those lines already. > > > > Hmm I was thinking something like this: > > > > drivers/base/device-loader.c > > drivers/misc/eeprom/beaglebone-cape.c > > > > Then you may be able to just load the configuration for it > > from a .dts file and maybe no hardware specific glue is even > > needed. > > > > At the end of the line, some kind of hardware glue is going to be needed. > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw > in the beagleboard), it is a bit premature to think about making it overly > general, besides the part that are obviously part of the infrastructure > (like the DT overlay stuff). > > What I'm getting at, is that we need some user experience about this, before > going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. 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
