2011/8/12 Dmitry Torokhov <dmitry.torok...@gmail.com>: > On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote: >> 2011/8/10 Mark Brown <broo...@opensource.wolfsonmicro.com>: >> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote: >> >> 2011/8/10 Mark Brown <broo...@opensource.wolfsonmicro.com>: >> > >> >> >> struct ads7846_platform_data { >> >> >> u16 model; /* 7843, 7845, 7846, 7873. */ >> >> >> u16 vref_mv; /* external vref value, >> >> >> milliVolts >> >> >> * ads7846: if 0, use internal >> >> >> vref */ >> > >> >> > There's some callbacks but the bulk of the structure (including the bits >> >> > I quoted above for example) looks like it's pure data and could sensibly >> >> > be represented in the device tree. >> > >> >> there have been many discussions about what should be in dts. >> >> basically, hardware information should be in dts, but data required by >> >> driver implementation should be not in dts. >> >> There are a lot of fields in the structure, not all can be a property >> >> as hardware information in dts. That means the driver need a lot of >> >> changes then. >> > >> > Things like the fields quoted above seem like they're fixed hardware >> > properties that oguht to be in the device tree, though. >> >> at least wakeup, irq_flags in the structure should be something >> related with driver implementation not hardware. Suppose all others >> are hardware properties, it looks terrible to list and get so many >> properties in dts and drivers. >> so do we have some simpler way to present a large number of properties in DT? >> BTW, even though we make all hardware information be properties in >> dts, drivers might still need some other platform_data only including >> software-related stuff for implementation. And Callback is also >> another big issue too. >> if we can't avoid software platform data and callbacks, there will >> still be some platform initilization codes in board files. > > Maybe should not add DT bindings for devices that can't be adequately > expressed via DT properties [yet]? Because I do not see what benefits we > get since platform code still needs to provide missing data and now we'd > have issue of data not being there when device is registered and driver > is being bound to it.
so it looks like a common issue for DT. what's your opinion, Grant? > > -- > Dmitry > -barry _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss