From: Tony Lindgren <tony@atomide.com>
To: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
Takashi Iwai <tiwai@suse.com>, Rob Herring <robh+dt@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCHv3 2/6] dt-bindings: sound: add motorola, cpcap-audio-codec
Date: Thu, 10 Aug 2017 09:53:59 -0700 [thread overview]
Message-ID: <20170810165358.GK8569@atomide.com> (raw)
In-Reply-To: <20170727090141.sxzm6mq5cv4jzucg@earth>
* Sebastian Reichel <sebastian.reichel@collabora.co.uk> [170727 02:02]:
> Hi,
>
> On Wed, Jul 26, 2017 at 12:48:28PM +0100, Mark Brown wrote:
> > On Tue, Jul 25, 2017 at 05:10:26PM +0200, Sebastian Reichel wrote:
> > > Motorola CPCAP is a PMIC with audio functionality, that can be
> > > found on Motorola Droid 4 and probably a few other phones from
> > > Motorola's Droid series.
> >
> > Please submit patches using subject lines reflecting the style for the
> > subsystem. This makes it easier for people to identify relevant
> > patches. Look at what existing commits in the area you're changing are
> > doing and make sure your subject lines visually resemble what they're
> > doing.
>
> Right, I did not notice, that ASoC does not follow general
> "dt-bindings: <subsys>:" DT bindings subject style. How
> do Rob and Mark find them?
>
> > > +&cpcap {
> > > + audio-codec {
> > > + compatible = "motorola,cpcap-audio-codec";
> > > + vdd-supply = <&vaudio>;
> > > + };
> > > +};
> >
> > I'd expect supplies (especially generically named supplies like this) to
> > be looked up at the chip level - aside from my general concerns with MFD
> > subnodes like this in the case of supplies it's especially problematic
> > as it makes it harder to do the generic chip level hookup in the DT and
> > it precludes other parts of the chip using the same supply (which seems
> > especially likely with a generically named supply like this).
>
> I don't follow you here. Why can't other parts of the chip use the
> same supply? Regarding the other point: Handling the audio-codec
> differently than all other sub-modules of cpcap seems much more
> problematic to me and the codec is basically the last one
> missing:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi
Mark, any comments on the above? I'm just wondering if the
related dts changes are safe for me to pick.
Regards,
Tony
next prev parent reply other threads:[~2017-08-10 16:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 15:10 [PATCHv3 0/6] Motorola Droid 4 Audio Support Sebastian Reichel
2017-07-25 15:10 ` [PATCHv3 1/6] ALSA: pcm: Export soc_dpcm_runtime_update Sebastian Reichel
2017-07-25 15:42 ` Takashi Iwai
2017-07-26 11:38 ` Mark Brown
2017-07-27 10:01 ` Sebastian Reichel
2017-07-25 15:10 ` [PATCHv3 2/6] dt-bindings: sound: add motorola,cpcap-audio-codec Sebastian Reichel
[not found] ` <20170725151030.26863-3-sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2017-07-26 11:48 ` Mark Brown
[not found] ` <20170726114827.pye3jm2b7x2nqo5v-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2017-07-27 9:01 ` Sebastian Reichel
2017-08-10 16:53 ` Tony Lindgren [this message]
2017-08-18 11:47 ` [PATCHv3 2/6] dt-bindings: sound: add motorola, cpcap-audio-codec Mark Brown
2017-07-25 15:10 ` [PATCHv3 3/6] ASoC: codec: cpcap: new codec Sebastian Reichel
2017-07-25 15:10 ` [PATCHv3 4/6] ARM: dts: motorola-cpcap-mapphone: add audio-codec Sebastian Reichel
2017-07-25 15:10 ` [PATCHv3 5/6] ARM: dts: motorola-cpcap-mapphone: set initial mode for vaudio Sebastian Reichel
2017-07-25 15:10 ` [PATCHv3 6/6] ARM: dts: omap4-droid4: add soundcard Sebastian Reichel
2017-07-27 12:01 ` [PATCHv3 0/6] Motorola Droid 4 Audio Support Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170810165358.GK8569@atomide.com \
--to=tony@atomide.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sebastian.reichel@collabora.co.uk \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).