| Message ID | 20170725151030.26863-3-sebastian.reichel@collabora.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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).
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
* 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
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 --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>; + }; +};