[alsa-devel] [PATCH] ASoC: Add device tree binding for WM8753

[Dmitry Torokhov]

On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:
> 2011/8/10 Mark Brown <broonie at opensource.wolfsonmicro.com>:
> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
> >> 2011/8/10 Mark Brown <broonie at 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.

-- 
Dmitry