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

[Barry Song]

2011/8/12 Dmitry Torokhov <dmitry.torokhov at gmail.com>:
> 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.

so it looks like a common issue for DT. what's your opinion, Grant?

>
> --
> Dmitry
>
-barry