[alsa-devel] [PATCH v2 5/5] ASoC: adau17x1: Support platform data via DT

Andreas Irestål andreas.irestal at axis.com
Wed Feb 17 09:58:29 CET 2016


On Tue, Feb 16, 2016 at 02:42:02PM +0100, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 13:56:45 Andreas Irestål wrote:
> > Currently, it is only possible to configure HW-specific options to the
> > adau17x1 codecs by providing a platform data struct. With this patch,
> > it is possible to provide the same data via DT instead.
> > 
> > Signed-off-by: Andreas Irestål <andire at axis.com>
> > ---
> >  .../devicetree/bindings/sound/adi,adau17x1.txt     |  31 +++++
> >  include/dt-bindings/sound/adau17x1.h               |  14 +++
> >  sound/soc/codecs/adau1761.c                        | 127 +++++++++++++++++++++
> >  sound/soc/codecs/adau1781.c                        |  48 ++++++++
> >  4 files changed, 220 insertions(+)
> >  create mode 100644 include/dt-bindings/sound/adau17x1.h
> 
> > +		of_pdata = devm_kzalloc(dev, sizeof(*of_pdata), GFP_KERNEL);
> > +		if (!of_pdata)
> > +			return -ENOMEM;
> > +		adau1781_pdata_from_of(dev, of_pdata);
> > +		dev->platform_data = of_pdata;
> 
> and here I'd try to avoid the dynamic allocation and just add the fields to the
> driver private structure. You can copy the information from the platform
> data in the 'else' path.

Since the driver private structure is shared between two different
codecs, the platform_data struct can be of 2 different types, but I
guess it should be OK to have two fields or a
union in the private struct.

I was thinking about this too but chose the approach above since providing
platform_data is optional. However, I could add some default values and
submit again.

Thanks a lot for the feedback.
/Andreas

> 
> 	Arnd


More information about the Alsa-devel mailing list