[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170711051540.GV3730@atomide.com>
Date: Mon, 10 Jul 2017 22:15:41 -0700
From: Tony Lindgren <tony@...mide.com>
To: Mark Brown <broonie@...nel.org>
Cc: Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
Sebastian Reichel <sre@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ASoC: codec: cpcap: new codec
* Mark Brown <broonie@...nel.org> [170710 10:52]:
> On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cpcap_audio_of_match[] = {
> > + { .compatible = "motorola,cpcap-audio-codec", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> > +#endif
>
> If this is part of a MFD shouldn't the parent device register it without
> it needing to be in the DT?
Having the MFD core part just do devm_of_platform_populate() leaves out
dependencies between the MFD core and it's child devices.
There are also a lot of board specific configuration to be done for many
child devices such as ADC wiring, GPIO pins used, and macro firmware
usage.
Not sure what all board specific stuff needs to be configured for this
driver yet, but it seems at least the macro interrupt wiring needs to
be configured. I would not be surprised to find GPIOs or ADC being used
for some connector detection too.
Regards,
Tony
Powered by blists - more mailing lists