2011/8/10 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
> On Wed, Aug 10, 2011 at 09:21:16AM +0800, Barry Song wrote:
>> 2011/8/9 Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>
>> > Oh, if that's the case the driver ought to have device tree bindings
>> > which replicate the platform data. Unless the platform data is
>> > sufficiently obscure for hardly anyone to want to use it I guess.
>
>> I guess what Dmitry said is the big ads7846_platform_data structure.
>
> Yes.
>
>> struct ads7846_platform_data {
>> u16 model; /* 7843, 7845, 7846, 7873. */
>> u16 vref_delay_usecs; /* 0 for external vref; etc */
>> u16 vref_mv; /* external vref value, milliVolts
>> * ads7846: if 0, use internal vref */
>> bool keep_vref_on; /* set to keep vref on for differential
>> * measurements as well */
>> bool swap_xy; /* swap x and y axes */
>
> ...
>
>> The structure even has some callbacks which can't be possible in dts.
>
> 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.
>
--
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
