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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/8/12 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>:
> On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:
>> 2011/8/10 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
>> >> 2011/8/10 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>> >
>> >> >>  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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux