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

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

[Barry Song]

2011/8/8 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Without this patch, DT can still connect driver with device by the
heuristic way(of_modalias_node).

i have a patch just like yours in input subsystem "[PATCH v2] input:
touchscreen: add OF match table for ads7846" with "Acked-by: Grant
Likely", but Dmitry seems to just ignore it.

so not sure whether this kind of new added match tables are totally
liked by people or not.

> ---
>  Documentation/devicetree/bindings/sound/wm8753.txt |   18 ++++++++++++++++++
>  sound/soc/codecs/wm8753.c                          |    9 +++++++++
>  2 files changed, 27 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/sound/wm8753.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/wm8753.txt b/Documentation/devicetree/bindings/sound/wm8753.txt
> new file mode 100644
> index 0000000..e65277a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/wm8753.txt
> @@ -0,0 +1,18 @@
> +WM8753 audio CODEC
> +
> +This device supports both I2C and SPI (configured with pin strapping
> +on the board).
> +
> +Required properties:
> +
> +  - compatible : "wlf,wm8753"
> +
> +  - reg : the I2C address of the device for I2C, the chip select
> +          number for SPI.
> +
> +Example:
> +
> +codec: wm8737@1a {
> +       compatible = "wlf,wm8753";
> +       reg = <0x1a>;
> +};
> diff --git a/sound/soc/codecs/wm8753.c b/sound/soc/codecs/wm8753.c
> index a702550..fe04a10 100644
> --- a/sound/soc/codecs/wm8753.c
> +++ b/sound/soc/codecs/wm8753.c
> @@ -38,6 +38,7 @@
>  #include <linux/delay.h>
>  #include <linux/pm.h>
>  #include <linux/i2c.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/spi/spi.h>
>  #include <linux/slab.h>
> @@ -1490,6 +1491,12 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8753 = {
>        .reg_cache_default = wm8753_reg,
>  };
>
> +static const struct of_device_id wm8753_of_match[] = {
> +       { .compatible = "wlf,wm8753", },
> +       { }
> +};
> +MODULE_DEVICE_TABLE(of, wm8753_of_match);
> +
>  #if defined(CONFIG_SPI_MASTER)
>  static int __devinit wm8753_spi_probe(struct spi_device *spi)
>  {
> @@ -1521,6 +1528,7 @@ static struct spi_driver wm8753_spi_driver = {
>        .driver = {
>                .name   = "wm8753",
>                .owner  = THIS_MODULE,
> +               .of_match_table = wm8753_of_match,
>        },
>        .probe          = wm8753_spi_probe,
>        .remove         = __devexit_p(wm8753_spi_remove),
> @@ -1565,6 +1573,7 @@ static struct i2c_driver wm8753_i2c_driver = {
>        .driver = {
>                .name = "wm8753",
>                .owner = THIS_MODULE,
> +               .of_match_table = wm8753_of_match,
>        },
>        .probe =    wm8753_i2c_probe,
>        .remove =   __devexit_p(wm8753_i2c_remove),
> --
> 1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

On Mon, Aug 08, 2011 at 04:38:41PM +0800, Barry Song wrote:
> 2011/8/8 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

> Without this patch, DT can still connect driver with device by the
> heuristic way(of_modalias_node).

Well, the other part of things is that it explicitly defines the
bindings (including qualification for the manufacturer, for Wolfson I
know we've got an occasional collision with chips from Wondermedia who
also use wm as a prefix for their part numbers).  The match tables
aren't particularly exciting in themselves but they're also very low
cost.

> 
> i have a patch just like yours in input subsystem "[PATCH v2] input:
> touchscreen: add OF match table for ads7846" with "Acked-by: Grant
> Likely", but Dmitry seems to just ignore it.
> 
> so not sure whether this kind of new added match tables are totally
> liked by people or not.
> 
> > ---
> >  Documentation/devicetree/bindings/sound/wm8753.txt |   18 ++++++++++++++++++
> >  sound/soc/codecs/wm8753.c                          |    9 +++++++++
> >  2 files changed, 27 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/sound/wm8753.txt
> >
> > diff --git a/Documentation/devicetree/bindings/sound/wm8753.txt b/Documentation/devicetree/bindings/sound/wm8753.txt
> > new file mode 100644
> > index 0000000..e65277a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/wm8753.txt
> > @@ -0,0 +1,18 @@
> > +WM8753 audio CODEC
> > +
> > +This device supports both I2C and SPI (configured with pin strapping
> > +on the board).
> > +
> > +Required properties:
> > +
> > +  - compatible : "wlf,wm8753"
> > +
> > +  - reg : the I2C address of the device for I2C, the chip select
> > +          number for SPI.
> > +
> > +Example:
> > +
> > +codec: wm8737@1a {
> > +       compatible = "wlf,wm8753";
> > +       reg = <0x1a>;
> > +};
> > diff --git a/sound/soc/codecs/wm8753.c b/sound/soc/codecs/wm8753.c
> > index a702550..fe04a10 100644
> > --- a/sound/soc/codecs/wm8753.c
> > +++ b/sound/soc/codecs/wm8753.c
> > @@ -38,6 +38,7 @@
> >  #include <linux/delay.h>
> >  #include <linux/pm.h>
> >  #include <linux/i2c.h>
> > +#include <linux/of_device.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/spi/spi.h>
> >  #include <linux/slab.h>
> > @@ -1490,6 +1491,12 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8753 = {
> >        .reg_cache_default = wm8753_reg,
> >  };
> >
> > +static const struct of_device_id wm8753_of_match[] = {
> > +       { .compatible = "wlf,wm8753", },
> > +       { }
> > +};
> > +MODULE_DEVICE_TABLE(of, wm8753_of_match);
> > +
> >  #if defined(CONFIG_SPI_MASTER)
> >  static int __devinit wm8753_spi_probe(struct spi_device *spi)
> >  {
> > @@ -1521,6 +1528,7 @@ static struct spi_driver wm8753_spi_driver = {
> >        .driver = {
> >                .name   = "wm8753",
> >                .owner  = THIS_MODULE,
> > +               .of_match_table = wm8753_of_match,
> >        },
> >        .probe          = wm8753_spi_probe,
> >        .remove         = __devexit_p(wm8753_spi_remove),
> > @@ -1565,6 +1573,7 @@ static struct i2c_driver wm8753_i2c_driver = {
> >        .driver = {
> >                .name = "wm8753",
> >                .owner = THIS_MODULE,
> > +               .of_match_table = wm8753_of_match,
> >        },
> >        .probe =    wm8753_i2c_probe,
> >        .remove =   __devexit_p(wm8753_i2c_remove),
> > --
> > 1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dmitry Torokhov]

Hi Barry,

On Mon, Aug 08, 2011 at 04:38:41PM +0800, Barry Song wrote:
> 2011/8/8 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> 
> Without this patch, DT can still connect driver with device by the
> heuristic way(of_modalias_node).
> 
> i have a patch just like yours in input subsystem "[PATCH v2] input:
> touchscreen: add OF match table for ads7846" with "Acked-by: Grant
> Likely", but Dmitry seems to just ignore it.
> 
> so not sure whether this kind of new added match tables are totally
> liked by people or not.

The issue I have with the ads7846 driver is that it still needs platform
code to supply the needed platform data structure to make the
driver/device usable. So I am not sure what the benefit DT matching code
brings to that driver.

Thanks.

-- 
Dmitry

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

[Mark Brown]

On Mon, Aug 08, 2011 at 11:51:00PM -0700, Dmitry Torokhov wrote:

> The issue I have with the ads7846 driver is that it still needs platform
> code to supply the needed platform data structure to make the
> driver/device usable. So I am not sure what the benefit DT matching code
> brings to that driver.

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.

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

[Barry Song]

2011/8/9 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Mon, Aug 08, 2011 at 11:51:00PM -0700, Dmitry Torokhov wrote:
>
>> The issue I have with the ads7846 driver is that it still needs platform
>> code to supply the needed platform data structure to make the
>> driver/device usable. So I am not sure what the benefit DT matching code
>> brings to that driver.
>
> 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.
>
With the device tree binding in ads7846, we don't need spi_board_info
any more since we have
ts@0 {
       compatible = "ti,ads7845";
       reg = <0x0>;
       spi-max-frequency = <31250>;
       interrupts = <90>;
};
in dts.

I guess what Dmitry said is the big ads7846_platform_data structure.

 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 */

        /* Settling time of the analog signals; a function of Vcc and the
         * capacitance on the X/Y drivers.  If set to non-zero, two samples
         * are taken with settle_delay us apart, and the second one is used.
         * ~150 uSec with 0.01uF caps.
         */
        u16     settle_delay_usecs;

        /* If set to non-zero, after samples are taken this delay is applied
         * and penirq is rechecked, to help avoid false events.  This value
         * is affected by the material used to build the touch layer.
         */
        u16     penirq_recheck_delay_usecs;

        u16     x_plate_ohms;
        u16     y_plate_ohms;

        u16     x_min, x_max;
        u16     y_min, y_max;
        u16     pressure_min, pressure_max;

        u16     debounce_max;           /* max number of additional readings
                                         * per sample */
        u16     debounce_tol;           /* tolerance used for filtering */
        u16     debounce_rep;           /* additional consecutive good readings
                                         * required after the first two */
        int     gpio_pendown;           /* the GPIO used to decide the pendown
                                         * state if get_pendown_state == NULL
                                         */
        int     (*get_pendown_state)(void);
        int     (*filter_init)  (const struct ads7846_platform_data *pdata,
                                 void **filter_data);
        int     (*filter)       (void *filter_data, int data_idx, int *val);
        void    (*filter_cleanup)(void *filter_data);
        void    (*wait_for_sync)(void);
        bool    wakeup;
        unsigned long irq_flags;
};

The structure even has some callbacks which can't be possible in dts.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

On Wed, Aug 10, 2011 at 09:21:16AM +0800, Barry Song wrote:
> 2011/8/9 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Barry Song]

2011/8/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Wed, Aug 10, 2011 at 09:21:16AM +0800, Barry Song wrote:
>> 2011/8/9 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>
>> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

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

[Barry Song]

2011/8/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
>> 2011/8/10 Mark Brown <broonie@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.
-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [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@opensource.wolfsonmicro.com>:
> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
> >> 2011/8/10 Mark Brown <broonie@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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Barry Song]

2011/8/12 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:
>> 2011/8/10 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>> > On Wed, Aug 10, 2011 at 01:57:11PM +0800, Barry Song wrote:
>> >> 2011/8/10 Mark Brown <broonie@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Mark Brown]

On Thu, 2011-08-11 at 20:53 -0700, Dmitry Torokhov wrote:
> On Fri, Aug 12, 2011 at 11:16:49AM +0800, Barry Song wrote:

> > 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.

It doesn't seem like this should be a blocker for moving the things we
can move, the conversion is going to need doing anyway so we may as well
get on with it. We always keep the platform data option around anyway as
not all platforms have converted to the device tree and it means that
systems that don't need to use any of the things that are difficult to
convert are able to convert.

In the case of wakeup there's already an API for controlling things at
runtime (device_may_wakeup() and so on) which the driver should probably
be converted to use, though I've not looked at what the actual platform
data does.

In the case of the IRQ flags we've got a generic problem that needs
solving at the IRQ level - the device is responsible for specifying the
flags but many devices are flexible about how they signal interrupts in
order to improve interoperability with controllers.

> 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.

You tend to find that in a lot of systems only need a subset of the
platform data - some of it can get pretty esoteric - or perhaps none at
all so they'll be able to run happily even if not everything can be
configured via the device tree.

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

[Dmitry Torokhov]

On Fri, Aug 12, 2011 at 01:41:22PM +0900, Mark Brown wrote:
> On Thu, 2011-08-11 at 20:53 -0700, Dmitry Torokhov wrote:
> 
> > 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.
> 
> You tend to find that in a lot of systems only need a subset of the
> platform data - some of it can get pretty esoteric - or perhaps none at
> all so they'll be able to run happily even if not everything can be
> configured via the device tree.

That is why I said "devices that can't be adequately expressed". If we
can have bindings that satisfy majority of users then of course DT
handling code is more than welcome.

-- 
Dmitry

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

[Mark Brown]

On Thu, 2011-08-11 at 22:57 -0700, Dmitry Torokhov wrote:
> On Fri, Aug 12, 2011 at 01:41:22PM +0900, Mark Brown wrote:

> > You tend to find that in a lot of systems only need a subset of the
> > platform data - some of it can get pretty esoteric - or perhaps none at
> > all so they'll be able to run happily even if not everything can be
> > configured via the device tree.

> That is why I said "devices that can't be adequately expressed". If we
> can have bindings that satisfy majority of users then of course DT
> handling code is more than welcome.

You seemed to be suggesting that devices that have platform data that
can't be expressed aren't worth adding DT support to - my point was that
the value is more dependant on the system needs than on the full feature
set that a driver can express.