diff mbox

[PATCHv3,2/6] dt-bindings: sound: add motorola, cpcap-audio-codec

Message ID 20170725151030.26863-3-sebastian.reichel@collabora.co.uk (mailing list archive)
State New, archived
Headers show

Commit Message

Sebastian Reichel July 25, 2017, 3:10 p.m. UTC
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.

This adds the DT binding for the codec sub-module found inside
the PMIC.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
 .../bindings/sound/motorola,cpcap-audio-codec.txt     | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt

Comments

Mark Brown July 26, 2017, 11:48 a.m. UTC | #1
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.

> +&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).
Sebastian Reichel July 27, 2017, 9:01 a.m. UTC | #2
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

-- Sebastian
Tony Lindgren Aug. 10, 2017, 4:53 p.m. UTC | #3
* 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
Mark Brown Aug. 18, 2017, 11:47 a.m. UTC | #4
On Thu, Aug 10, 2017 at 09:53:59AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel <sebastian.reichel@collabora.co.uk> [170727 02:02]:

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

They can, they know they're part of the parent chip and should be
looking for the supply on the chip level.

> > differently than all other sub-modules of cpcap seems much more
> > problematic to me and the codec is basically the last one
> > missing:

> Mark, any comments on the above? I'm just wondering if the
> related dts changes are safe for me to pick.

No, they don't make sense.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt b/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
new file mode 100644
index 000000000000..6b8cd616bd46
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/motorola,cpcap-audio-codec.txt
@@ -0,0 +1,19 @@ 
+Motorola CPCAP audio CODEC
+--------------------------
+
+This module is part of the CPCAP. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
+
+Required properties:
+
+  - compatible : "motorola,cpcap-audio-codec"
+  - vdd-supply : Phandle to audio regulator
+
+Example:
+
+&cpcap {
+	audio-codec {
+		compatible = "motorola,cpcap-audio-codec";
+		vdd-supply = <&vaudio>;
+	};
+};