[PATCH v2] arm: dts: hummingboard: convert onboard audio to simple-audio-card
The HB onboard audio currently makes use of the imx-audio-sgtl5000
binding. This binding does not support auxiliary audio devices such
as external amplifiers. The simple-audio-card binding does support
this property which allows systems incorporating the HB to add an
auxiliary device that's attached to the HB audio jack with an
overlay. Convert the HB onboard audio to use simple-audio-card for
this additional flexibility.
Signed-off-by: Matt Porter <mpor...@konsulko.com>
Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>
---
v2:
- also convert HB1 to simple-audio-card
- retain original card name as "On-board Codec" [case change]
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 52 ++--
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 48 -
2 files changed, 82 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 92583238ca4a..2f6e51fbd4bc 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -38,6 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
/ {
chosen {
@@ -105,17 +106,27 @@
vin-supply = <_5v0>;
};
- sound-sgtl5000 {
- audio-codec = <>;
- audio-routing =
- "MIC_IN", "Mic Jack",
- "Mic Jack", "Mic Bias",
+ audio: sound-sgtl5000 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-board Codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+ simple-audio-card,widgets =
+ "Microphone", "Headphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Headphone Jack",
+ "Headphone Jack", "Mic Bias",
"Headphone Jack", "HP_OUT";
- compatible = "fsl,imx-audio-sgtl5000";
- model = "On-board Codec";
- mux-ext-port = <5>;
- mux-int-port = <1>;
- ssi-controller = <>;
+
+ sound_cpu: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ sound_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ };
};
sound-spdif {
@@ -129,6 +140,26 @@
{
status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_SYN |
+IMX_AUDMUX_V2_PTCR_TFSEL(4) |
+IMX_AUDMUX_V2_PTCR_TCSEL(4) |
+IMX_AUDMUX_V2_PTCR_TFSDIR |
+IMX_AUDMUX_V2_PTCR_TCLKDIR)
+IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ pins5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ >;
+ };
};
{
@@ -161,6 +192,7 @@
compatible = "fsl,sgtl5000";
pinctrl-names = "default";
pinctrl-0 = <_hummingboard_sgtl5000>;
+ #sound-dai-cells = <0>;
reg = <0x0a>;
VDDA-supply = <_3v2>;
VDDIO-supply = <_3v2>;
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index dffbc92e0023..47d780fafd87 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -38,6 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
/ {
chosen {
@@ -145,22 +146,52 @@
vin-supply = <_5v0>;
};
- sound-sgtl5000 {
- audio-codec = <>;
- audio-routing =
+ audio: sound-sgtl5000 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-board Codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <
[PATCH v2] arm: dts: hummingboard: convert onboard audio to simple-audio-card
The HB onboard audio currently makes use of the imx-audio-sgtl5000
binding. This binding does not support auxiliary audio devices such
as external amplifiers. The simple-audio-card binding does support
this property which allows systems incorporating the HB to add an
auxiliary device that's attached to the HB audio jack with an
overlay. Convert the HB onboard audio to use simple-audio-card for
this additional flexibility.
Signed-off-by: Matt Porter
Reviewed-by: Fabio Estevam
---
v2:
- also convert HB1 to simple-audio-card
- retain original card name as "On-board Codec" [case change]
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 52 ++--
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 48 -
2 files changed, 82 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 92583238ca4a..2f6e51fbd4bc 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -38,6 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
/ {
chosen {
@@ -105,17 +106,27 @@
vin-supply = <_5v0>;
};
- sound-sgtl5000 {
- audio-codec = <>;
- audio-routing =
- "MIC_IN", "Mic Jack",
- "Mic Jack", "Mic Bias",
+ audio: sound-sgtl5000 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-board Codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+ simple-audio-card,widgets =
+ "Microphone", "Headphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Headphone Jack",
+ "Headphone Jack", "Mic Bias",
"Headphone Jack", "HP_OUT";
- compatible = "fsl,imx-audio-sgtl5000";
- model = "On-board Codec";
- mux-ext-port = <5>;
- mux-int-port = <1>;
- ssi-controller = <>;
+
+ sound_cpu: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ sound_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ };
};
sound-spdif {
@@ -129,6 +140,26 @@
{
status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_SYN |
+IMX_AUDMUX_V2_PTCR_TFSEL(4) |
+IMX_AUDMUX_V2_PTCR_TCSEL(4) |
+IMX_AUDMUX_V2_PTCR_TFSDIR |
+IMX_AUDMUX_V2_PTCR_TCLKDIR)
+IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ pins5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ >;
+ };
};
{
@@ -161,6 +192,7 @@
compatible = "fsl,sgtl5000";
pinctrl-names = "default";
pinctrl-0 = <_hummingboard_sgtl5000>;
+ #sound-dai-cells = <0>;
reg = <0x0a>;
VDDA-supply = <_3v2>;
VDDIO-supply = <_3v2>;
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index dffbc92e0023..47d780fafd87 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -38,6 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
/ {
chosen {
@@ -145,22 +146,52 @@
vin-supply = <_5v0>;
};
- sound-sgtl5000 {
- audio-codec = <>;
- audio-routing =
+ audio: sound-sgtl5000 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-board Codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+ simple-audio-card,widgets
Re: [PATCH] arm: dts: hummingboard2: convert onboard audio to simple-audio-card
On Mon, Mar 19, 2018 at 02:23:50PM +, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2018 at 09:53:26AM -0400, Matt Porter wrote:
> > The HB2 onboard audio currently makes use of the imx-audio-sgtl5000
> > binding. This binding does not support auxiliary audio devices such
> > as external amplifiers. The simple-audio-card binding does support
> > this property which allows systems incorporating the HB2 to easily
> > add an auxiliary device that's attached to the HB2 audio jack with
> > an overlay. Convert HB2 to use simple-audio-card for the onboard
> > audio to allow for this additional flexibility.
>
> What is driving this change?
I have an HB2 that's incorporated in a platform that includes an
audio processor (tda7419) and external amplifier (tda7850) attached to
the HB2 headphone out. The tda7419 also handles two additional non-Linux
audio source inputs, FWIW. The tda7419 and tda7850 are supported as
ASoC component drivers. However, they must be added to a card as
auxiliary devices to be instantiated and have their controls exposed
to userspace. In addition, once added as an aux device, the tda7419
muxes and switches can participate in DAPM properly. Using
simple-audio-card enables this option, without giving up any of the
current functionality when using imx-audio-sgtl5000.
>Why only make this change for HB2 and not HB?
I was a little fixated on the HB2 platform that I'm working on. It's
equally applicable to HB so I can add the same change there.
-Matt
> > Signed-off-by: Matt Porter <mpor...@konsulko.com>
> > ---
> > arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 48
> > +++-
> > 1 file changed, 40 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > index dffbc92e0023..587251ab76ec 100644
> > --- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > @@ -38,6 +38,7 @@
> > * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > * OTHER DEALINGS IN THE SOFTWARE.
> > */
> > +#include
> >
> > / {
> > chosen {
> > @@ -145,22 +146,52 @@
> > vin-supply = <_5v0>;
> > };
> >
> > - sound-sgtl5000 {
> > - audio-codec = <>;
> > - audio-routing =
> > + audio: sound-sgtl5000 {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,name = "On-Board Codec";
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,bitclock-master = <_codec>;
> > + simple-audio-card,frame-master = <_codec>;
> > + simple-audio-card,widgets =
> > + "Microphone", "Mic Jack",
> > + "Headphone", "Headphone Jack";
> > + simple-audio-card,routing =
> > "MIC_IN", "Mic Jack",
> > "Mic Jack", "Mic Bias",
> > "Headphone Jack", "HP_OUT";
> > - compatible = "fsl,imx-audio-sgtl5000";
> > - model = "On-board Codec";
> > - mux-ext-port = <5>;
> > - mux-int-port = <1>;
> > - ssi-controller = <>;
> > +
> > + sound_cpu: simple-audio-card,cpu {
> > + sound-dai = <>;
> > + };
> > +
> > + sound_codec: simple-audio-card,codec {
> > + sound-dai = <>;
> > + };
> > };
> > };
> >
> > {
> > status = "okay";
> > +
> > + ssi1 {
> > + fsl,audmux-port = <0>;
> > + fsl,port-config = <
> > + (IMX_AUDMUX_V2_PTCR_SYN |
> > +IMX_AUDMUX_V2_PTCR_TFSEL(4) |
> > +IMX_AUDMUX_V2_PTCR_TCSEL(4) |
> > +IMX_AUDMUX_V2_PTCR_TFSDIR |
> > +IMX_AUDMUX_V2_PTCR_TCLKDIR)
> > +IMX_AUDMUX_V2_PDCR_RXDSEL(4)
> > + >;
> > + };
> > +
> > + pins5 {
> > + fsl,audmux-port = <4>;
> > + fsl,port-config = <
> > + IMX_AUDMUX_V2_PTCR_SYN
> > + IMX_AUDMUX_V2_PDCR_RXDSEL(0)
> > + >;
> > + };
> > };
> >
> > {
> > @@ -193,6 +224,7 @@
> > compatible = "fsl,sgtl5000";
> > pinctrl-names = "default";
> > pinctrl-0 = <_hummingboard2_sgtl5000>;
> > + #sound-dai-cells = <0>;
> > reg = <0x0a>;
> > VDDA-supply = <_3v2>;
> > VDDD-supply = <_1p8>;
> > --
> > 2.11.0
> >
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
Re: [PATCH] arm: dts: hummingboard2: convert onboard audio to simple-audio-card
On Mon, Mar 19, 2018 at 02:23:50PM +, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2018 at 09:53:26AM -0400, Matt Porter wrote:
> > The HB2 onboard audio currently makes use of the imx-audio-sgtl5000
> > binding. This binding does not support auxiliary audio devices such
> > as external amplifiers. The simple-audio-card binding does support
> > this property which allows systems incorporating the HB2 to easily
> > add an auxiliary device that's attached to the HB2 audio jack with
> > an overlay. Convert HB2 to use simple-audio-card for the onboard
> > audio to allow for this additional flexibility.
>
> What is driving this change?
I have an HB2 that's incorporated in a platform that includes an
audio processor (tda7419) and external amplifier (tda7850) attached to
the HB2 headphone out. The tda7419 also handles two additional non-Linux
audio source inputs, FWIW. The tda7419 and tda7850 are supported as
ASoC component drivers. However, they must be added to a card as
auxiliary devices to be instantiated and have their controls exposed
to userspace. In addition, once added as an aux device, the tda7419
muxes and switches can participate in DAPM properly. Using
simple-audio-card enables this option, without giving up any of the
current functionality when using imx-audio-sgtl5000.
>Why only make this change for HB2 and not HB?
I was a little fixated on the HB2 platform that I'm working on. It's
equally applicable to HB so I can add the same change there.
-Matt
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 48
> > +++-
> > 1 file changed, 40 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > index dffbc92e0023..587251ab76ec 100644
> > --- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > @@ -38,6 +38,7 @@
> > * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > * OTHER DEALINGS IN THE SOFTWARE.
> > */
> > +#include
> >
> > / {
> > chosen {
> > @@ -145,22 +146,52 @@
> > vin-supply = <_5v0>;
> > };
> >
> > - sound-sgtl5000 {
> > - audio-codec = <>;
> > - audio-routing =
> > + audio: sound-sgtl5000 {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,name = "On-Board Codec";
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,bitclock-master = <_codec>;
> > + simple-audio-card,frame-master = <_codec>;
> > + simple-audio-card,widgets =
> > + "Microphone", "Mic Jack",
> > + "Headphone", "Headphone Jack";
> > + simple-audio-card,routing =
> > "MIC_IN", "Mic Jack",
> > "Mic Jack", "Mic Bias",
> > "Headphone Jack", "HP_OUT";
> > - compatible = "fsl,imx-audio-sgtl5000";
> > - model = "On-board Codec";
> > - mux-ext-port = <5>;
> > - mux-int-port = <1>;
> > - ssi-controller = <>;
> > +
> > + sound_cpu: simple-audio-card,cpu {
> > + sound-dai = <>;
> > + };
> > +
> > + sound_codec: simple-audio-card,codec {
> > + sound-dai = <>;
> > + };
> > };
> > };
> >
> > {
> > status = "okay";
> > +
> > + ssi1 {
> > + fsl,audmux-port = <0>;
> > + fsl,port-config = <
> > + (IMX_AUDMUX_V2_PTCR_SYN |
> > +IMX_AUDMUX_V2_PTCR_TFSEL(4) |
> > +IMX_AUDMUX_V2_PTCR_TCSEL(4) |
> > +IMX_AUDMUX_V2_PTCR_TFSDIR |
> > +IMX_AUDMUX_V2_PTCR_TCLKDIR)
> > +IMX_AUDMUX_V2_PDCR_RXDSEL(4)
> > + >;
> > + };
> > +
> > + pins5 {
> > + fsl,audmux-port = <4>;
> > + fsl,port-config = <
> > + IMX_AUDMUX_V2_PTCR_SYN
> > + IMX_AUDMUX_V2_PDCR_RXDSEL(0)
> > + >;
> > + };
> > };
> >
> > {
> > @@ -193,6 +224,7 @@
> > compatible = "fsl,sgtl5000";
> > pinctrl-names = "default";
> > pinctrl-0 = <_hummingboard2_sgtl5000>;
> > + #sound-dai-cells = <0>;
> > reg = <0x0a>;
> > VDDA-supply = <_3v2>;
> > VDDD-supply = <_1p8>;
> > --
> > 2.11.0
> >
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
[PATCH] arm: dts: hummingboard2: convert onboard audio to simple-audio-card
The HB2 onboard audio currently makes use of the imx-audio-sgtl5000
binding. This binding does not support auxiliary audio devices such
as external amplifiers. The simple-audio-card binding does support
this property which allows systems incorporating the HB2 to easily
add an auxiliary device that's attached to the HB2 audio jack with
an overlay. Convert HB2 to use simple-audio-card for the onboard
audio to allow for this additional flexibility.
Signed-off-by: Matt Porter <mpor...@konsulko.com>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 48 +++-
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index dffbc92e0023..587251ab76ec 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -38,6 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
/ {
chosen {
@@ -145,22 +146,52 @@
vin-supply = <_5v0>;
};
- sound-sgtl5000 {
- audio-codec = <>;
- audio-routing =
+ audio: sound-sgtl5000 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-Board Codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
"MIC_IN", "Mic Jack",
"Mic Jack", "Mic Bias",
"Headphone Jack", "HP_OUT";
- compatible = "fsl,imx-audio-sgtl5000";
- model = "On-board Codec";
- mux-ext-port = <5>;
- mux-int-port = <1>;
- ssi-controller = <>;
+
+ sound_cpu: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ sound_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ };
};
};
{
status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_SYN |
+IMX_AUDMUX_V2_PTCR_TFSEL(4) |
+IMX_AUDMUX_V2_PTCR_TCSEL(4) |
+IMX_AUDMUX_V2_PTCR_TFSDIR |
+IMX_AUDMUX_V2_PTCR_TCLKDIR)
+IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ pins5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ >;
+ };
};
{
@@ -193,6 +224,7 @@
compatible = "fsl,sgtl5000";
pinctrl-names = "default";
pinctrl-0 = <_hummingboard2_sgtl5000>;
+ #sound-dai-cells = <0>;
reg = <0x0a>;
VDDA-supply = <_3v2>;
VDDD-supply = <_1p8>;
--
2.11.0
[PATCH] arm: dts: hummingboard2: convert onboard audio to simple-audio-card
The HB2 onboard audio currently makes use of the imx-audio-sgtl5000
binding. This binding does not support auxiliary audio devices such
as external amplifiers. The simple-audio-card binding does support
this property which allows systems incorporating the HB2 to easily
add an auxiliary device that's attached to the HB2 audio jack with
an overlay. Convert HB2 to use simple-audio-card for the onboard
audio to allow for this additional flexibility.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 48 +++-
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index dffbc92e0023..587251ab76ec 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -38,6 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
/ {
chosen {
@@ -145,22 +146,52 @@
vin-supply = <_5v0>;
};
- sound-sgtl5000 {
- audio-codec = <>;
- audio-routing =
+ audio: sound-sgtl5000 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-Board Codec";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <_codec>;
+ simple-audio-card,frame-master = <_codec>;
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
"MIC_IN", "Mic Jack",
"Mic Jack", "Mic Bias",
"Headphone Jack", "HP_OUT";
- compatible = "fsl,imx-audio-sgtl5000";
- model = "On-board Codec";
- mux-ext-port = <5>;
- mux-int-port = <1>;
- ssi-controller = <>;
+
+ sound_cpu: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ sound_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ };
};
};
{
status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_SYN |
+IMX_AUDMUX_V2_PTCR_TFSEL(4) |
+IMX_AUDMUX_V2_PTCR_TCSEL(4) |
+IMX_AUDMUX_V2_PTCR_TFSDIR |
+IMX_AUDMUX_V2_PTCR_TCLKDIR)
+IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ pins5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ >;
+ };
};
{
@@ -193,6 +224,7 @@
compatible = "fsl,sgtl5000";
pinctrl-names = "default";
pinctrl-0 = <_hummingboard2_sgtl5000>;
+ #sound-dai-cells = <0>;
reg = <0x0a>;
VDDA-supply = <_3v2>;
VDDD-supply = <_1p8>;
--
2.11.0
[PATCH v2 2/2] ASoC: add tda7419 audio processor driver
Component driver for the tda7419 audio processor. Signed-off-by: Matt Porter <mpor...@konsulko.com> --- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 654 + 3 files changed, 662 insertions(+) create mode 100644 sound/soc/codecs/tda7419.c diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 2b331f7266ab..1553cf2b9445 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -151,6 +151,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TAS571X if I2C select SND_SOC_TAS5720 if I2C select SND_SOC_TAS6424 if I2C + select SND_SOC_TDA7419 if I2C select SND_SOC_TFA9879 if I2C select SND_SOC_TLV320AIC23_I2C if I2C select SND_SOC_TLV320AIC23_SPI if SPI_MASTER @@ -910,6 +911,11 @@ config SND_SOC_TAS6424 Enable support for Texas Instruments TAS6424 high-efficiency digital input quad-channel Class-D audio power amplifiers. +config SND_SOC_TDA7419 + tristate "ST TDA7419 audio processor" + depends on I2C + select REGMAP_I2C + config SND_SOC_TFA9879 tristate "NXP Semiconductors TFA9879 amplifier" depends on I2C diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index da1571336f1e..6cf3c3b92cb5 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -160,6 +160,7 @@ snd-soc-tas5086-objs := tas5086.o snd-soc-tas571x-objs := tas571x.o snd-soc-tas5720-objs := tas5720.o snd-soc-tas6424-objs := tas6424.o +snd-soc-tda7419-objs := tda7419.o snd-soc-tfa9879-objs := tfa9879.o snd-soc-tlv320aic23-objs := tlv320aic23.o snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o @@ -405,6 +406,7 @@ obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o obj-$(CONFIG_SND_SOC_TAS5720) += snd-soc-tas5720.o obj-$(CONFIG_SND_SOC_TAS6424) += snd-soc-tas6424.o +obj-$(CONFIG_SND_SOC_TDA7419) += snd-soc-tda7419.o obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o diff --git a/sound/soc/codecs/tda7419.c b/sound/soc/codecs/tda7419.c new file mode 100644 index ..225c210ac38f --- /dev/null +++ b/sound/soc/codecs/tda7419.c @@ -0,0 +1,654 @@ +/* + * TDA7419 audio processor driver + * + * Copyright 2018 Konsulko Group + * + * Author: Matt Porter <mpor...@konsulko.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define TDA7419_MAIN_SRC_REG 0x00 +#define TDA7419_LOUDNESS_REG 0x01 +#define TDA7419_MUTE_CLK_REG 0x02 +#define TDA7419_VOLUME_REG 0x03 +#define TDA7419_TREBLE_REG 0x04 +#define TDA7419_MIDDLE_REG 0x05 +#define TDA7419_BASS_REG 0x06 +#define TDA7419_SECOND_SRC_REG 0x07 +#define TDA7419_SUB_MID_BASS_REG 0x08 +#define TDA7419_MIXING_GAIN_REG0x09 +#define TDA7419_ATTENUATOR_LF_REG 0x0a +#define TDA7419_ATTENUATOR_RF_REG 0x0b +#define TDA7419_ATTENUATOR_LR_REG 0x0c +#define TDA7419_ATTENUATOR_RR_REG 0x0d +#define TDA7419_MIXING_LEVEL_REG 0x0e +#define TDA7419_ATTENUATOR_SUB_REG 0x0f +#define TDA7419_SA_CLK_AC_REG 0x10 +#define TDA7419_TESTING_REG0x11 + +#define TDA7419_MAIN_SRC_SEL 0 +#define TDA7419_MAIN_SRC_GAIN 3 +#define TDA7419_MAIN_SRC_AUTOZERO 7 + +#define TDA7419_LOUDNESS_ATTEN 0 +#define TDA7419_LOUDNESS_CENTER_FREQ 4 +#define TDA7419_LOUDNESS_BOOST 6 +#define TDA7419_LOUDNESS_SOFT_STEP 7 + +#define TDA7419_VOLUME_SOFT_STEP 7 + +#define TDA7419_SOFT_MUTE 0 +#define TDA7419_MUTE_INFLUENCE 1 +#define TDA7419_SOFT_MUTE_TIME 2 +#define TDA7419_SOFT_STEP_TIME 4 +#define TDA7419_CLK_FAST_MODE 7 + +#define TDA7419_TREBLE_CENTER_FREQ 5 +#define TDA7419_REF_OUT_SELECT 7 + +#define TDA7419_MIDDLE_Q_FACTOR5 +#define TDA7419_MIDDLE_SOFT_STEP 7 + +#define TDA7419_BASS_Q_FACTOR 5 +#define TDA7419_BASS_SOFT_STEP 7 + +#define TDA7419_SECOND_SRC_SEL 0 +#define TDA7419_SECOND_SRC_GAIN3 +#define TDA7419_REAR_SPKR_SRC 7 + +#define TDA7419_SUB_CUT_OFF_FREQ 0 +#define TDA7419_MIDDLE_CENTER_FREQ 2 +#define TDA7419_B
[PATCH v2 2/2] ASoC: add tda7419 audio processor driver
Component driver for the tda7419 audio processor. Signed-off-by: Matt Porter --- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 654 + 3 files changed, 662 insertions(+) create mode 100644 sound/soc/codecs/tda7419.c diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 2b331f7266ab..1553cf2b9445 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -151,6 +151,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TAS571X if I2C select SND_SOC_TAS5720 if I2C select SND_SOC_TAS6424 if I2C + select SND_SOC_TDA7419 if I2C select SND_SOC_TFA9879 if I2C select SND_SOC_TLV320AIC23_I2C if I2C select SND_SOC_TLV320AIC23_SPI if SPI_MASTER @@ -910,6 +911,11 @@ config SND_SOC_TAS6424 Enable support for Texas Instruments TAS6424 high-efficiency digital input quad-channel Class-D audio power amplifiers. +config SND_SOC_TDA7419 + tristate "ST TDA7419 audio processor" + depends on I2C + select REGMAP_I2C + config SND_SOC_TFA9879 tristate "NXP Semiconductors TFA9879 amplifier" depends on I2C diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index da1571336f1e..6cf3c3b92cb5 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -160,6 +160,7 @@ snd-soc-tas5086-objs := tas5086.o snd-soc-tas571x-objs := tas571x.o snd-soc-tas5720-objs := tas5720.o snd-soc-tas6424-objs := tas6424.o +snd-soc-tda7419-objs := tda7419.o snd-soc-tfa9879-objs := tfa9879.o snd-soc-tlv320aic23-objs := tlv320aic23.o snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o @@ -405,6 +406,7 @@ obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o obj-$(CONFIG_SND_SOC_TAS5720) += snd-soc-tas5720.o obj-$(CONFIG_SND_SOC_TAS6424) += snd-soc-tas6424.o +obj-$(CONFIG_SND_SOC_TDA7419) += snd-soc-tda7419.o obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o diff --git a/sound/soc/codecs/tda7419.c b/sound/soc/codecs/tda7419.c new file mode 100644 index ..225c210ac38f --- /dev/null +++ b/sound/soc/codecs/tda7419.c @@ -0,0 +1,654 @@ +/* + * TDA7419 audio processor driver + * + * Copyright 2018 Konsulko Group + * + * Author: Matt Porter + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define TDA7419_MAIN_SRC_REG 0x00 +#define TDA7419_LOUDNESS_REG 0x01 +#define TDA7419_MUTE_CLK_REG 0x02 +#define TDA7419_VOLUME_REG 0x03 +#define TDA7419_TREBLE_REG 0x04 +#define TDA7419_MIDDLE_REG 0x05 +#define TDA7419_BASS_REG 0x06 +#define TDA7419_SECOND_SRC_REG 0x07 +#define TDA7419_SUB_MID_BASS_REG 0x08 +#define TDA7419_MIXING_GAIN_REG0x09 +#define TDA7419_ATTENUATOR_LF_REG 0x0a +#define TDA7419_ATTENUATOR_RF_REG 0x0b +#define TDA7419_ATTENUATOR_LR_REG 0x0c +#define TDA7419_ATTENUATOR_RR_REG 0x0d +#define TDA7419_MIXING_LEVEL_REG 0x0e +#define TDA7419_ATTENUATOR_SUB_REG 0x0f +#define TDA7419_SA_CLK_AC_REG 0x10 +#define TDA7419_TESTING_REG0x11 + +#define TDA7419_MAIN_SRC_SEL 0 +#define TDA7419_MAIN_SRC_GAIN 3 +#define TDA7419_MAIN_SRC_AUTOZERO 7 + +#define TDA7419_LOUDNESS_ATTEN 0 +#define TDA7419_LOUDNESS_CENTER_FREQ 4 +#define TDA7419_LOUDNESS_BOOST 6 +#define TDA7419_LOUDNESS_SOFT_STEP 7 + +#define TDA7419_VOLUME_SOFT_STEP 7 + +#define TDA7419_SOFT_MUTE 0 +#define TDA7419_MUTE_INFLUENCE 1 +#define TDA7419_SOFT_MUTE_TIME 2 +#define TDA7419_SOFT_STEP_TIME 4 +#define TDA7419_CLK_FAST_MODE 7 + +#define TDA7419_TREBLE_CENTER_FREQ 5 +#define TDA7419_REF_OUT_SELECT 7 + +#define TDA7419_MIDDLE_Q_FACTOR5 +#define TDA7419_MIDDLE_SOFT_STEP 7 + +#define TDA7419_BASS_Q_FACTOR 5 +#define TDA7419_BASS_SOFT_STEP 7 + +#define TDA7419_SECOND_SRC_SEL 0 +#define TDA7419_SECOND_SRC_GAIN3 +#define TDA7419_REAR_SPKR_SRC 7 + +#define TDA7419_SUB_CUT_OFF_FREQ 0 +#define TDA7419_MIDDLE_CENTER_FREQ 2 +#define TDA7419_BASS_CENTER_FREQ 4 +#define TDA7419_BASS_DC_MODE
[PATCH v2 1/2] ASoC: add tda7419 audio processor binding
DeviceTree binding for the tda7419 audio processor.
Signed-off-by: Matt Porter <mpor...@konsulko.com>
---
.../devicetree/bindings/sound/tda7419.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt
diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt
b/Documentation/devicetree/bindings/sound/tda7419.txt
new file mode 100644
index ..6b85ec38dd56
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tda7419.txt
@@ -0,0 +1,38 @@
+TDA7419 audio processor
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "st,tda7419"
+- reg : the I2C address of the device.
+- vdd-supply : a regulator spec for the common power supply (8-10V)
+
+Optional properties:
+
+- st,mute-gpios : a GPIO spec for the MUTE pin.
+
+Pins on the device (for linking into audio routes):
+
+ * SE3L
+ * SE3R
+ * SE2L
+ * SE2R
+ * SE1L
+ * SE1R
+ * DIFFL
+ * DIFFR
+ * MIX
+ * OUTLF
+ * OUTRF
+ * OUTLR
+ * OUTRR
+ * OUTSW
+
+Example:
+
+ap: tda7419@44 {
+ compatible = "st,tda7419";
+ reg = <0x44>;
+ vdd-supply = <_9v0_reg>;
+};
--
2.11.0
[PATCH v2 1/2] ASoC: add tda7419 audio processor binding
DeviceTree binding for the tda7419 audio processor.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/sound/tda7419.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt
diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt
b/Documentation/devicetree/bindings/sound/tda7419.txt
new file mode 100644
index ..6b85ec38dd56
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tda7419.txt
@@ -0,0 +1,38 @@
+TDA7419 audio processor
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "st,tda7419"
+- reg : the I2C address of the device.
+- vdd-supply : a regulator spec for the common power supply (8-10V)
+
+Optional properties:
+
+- st,mute-gpios : a GPIO spec for the MUTE pin.
+
+Pins on the device (for linking into audio routes):
+
+ * SE3L
+ * SE3R
+ * SE2L
+ * SE2R
+ * SE1L
+ * SE1R
+ * DIFFL
+ * DIFFR
+ * MIX
+ * OUTLF
+ * OUTRF
+ * OUTLR
+ * OUTRR
+ * OUTSW
+
+Example:
+
+ap: tda7419@44 {
+ compatible = "st,tda7419";
+ reg = <0x44>;
+ vdd-supply = <_9v0_reg>;
+};
--
2.11.0
[PATCH v2 0/2] TDA7419 audio processor driver
This series adds an ASoC component driver for the ST TDA7419 audio processor which is commonly used in automotive audio applications. The datasheet can be found at http://www.st.com/resource/en/datasheet/tda7419.pdf Changes since v1: * add supply and mute gpios to binding * remove writeable register, already the default * add "Switch" to all switch controls * move register default reset to probe and comment * rework part-specific volume handling to handle register power-on default values * remove custom register init values * add audio route pins to binding * add DAPM support Matt Porter (2): ASoC: add tda7419 audio processor binding ASoC: add tda7419 audio processor driver .../devicetree/bindings/sound/tda7419.txt | 38 ++ sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 654 + 4 files changed, 700 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt create mode 100644 sound/soc/codecs/tda7419.c -- 2.11.0
[PATCH v2 0/2] TDA7419 audio processor driver
This series adds an ASoC component driver for the ST TDA7419 audio processor which is commonly used in automotive audio applications. The datasheet can be found at http://www.st.com/resource/en/datasheet/tda7419.pdf Changes since v1: * add supply and mute gpios to binding * remove writeable register, already the default * add "Switch" to all switch controls * move register default reset to probe and comment * rework part-specific volume handling to handle register power-on default values * remove custom register init values * add audio route pins to binding * add DAPM support Matt Porter (2): ASoC: add tda7419 audio processor binding ASoC: add tda7419 audio processor driver .../devicetree/bindings/sound/tda7419.txt | 38 ++ sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 654 + 4 files changed, 700 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt create mode 100644 sound/soc/codecs/tda7419.c -- 2.11.0
Re: [PATCH 2/2] ASoC: add tda7419 audio processor driver
On Fri, Mar 09, 2018 at 03:29:12PM +, Mark Brown wrote:
> On Fri, Mar 09, 2018 at 09:35:48AM -0500, Matt Porter wrote:
> > On Wed, Feb 28, 2018 at 11:00:38AM +, Mark Brown wrote:
> > > On Tue, Feb 27, 2018 at 05:51:28PM -0500, Matt Porter wrote:
>
> > > > +static struct snd_kcontrol_new tda7419_controls[] = {
> > > > +SOC_ENUM("Main Source Select", soc_enum_main_src_sel),
>
> > > Should this be a DAPM route?
>
> > Ultimately yes. I initially took the path of ignoring DAPM support in
> > interests of getting some clean done. Is it ok to merge DAPM support
> > later or do you prefer just having it in the intitial driver? For
> > routes, it'll include Main/Second source selects, the Rear Source
> > switch, and Mix enable at least.
>
> You definitely shouldn't be implementing things that should be in DAPM
> as non-DAPM controls.
Ok, I addressed this by adding DAPM support in v2.
> > > > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_SUB_REG, 0xe0);
>
> > > This looks like it's setting default volumes - just leave those at the
> > > chip defaults and let userspace handle setting them, what works for one
> > > board may be totally inappropriate on another board and using the chip
> > > default means we've got some fixed thing we don't need to discuss.
>
> > This is actually setting the default/cache to the first mute value due
> > to the assumption in my implementation of the tda7419-specific get/set
> > for these registers. It simplified the code a bit to have these
> > initialized like this. e.g. for the attenuator group of registers,
> > x11x are all mute values, so 0xe0 is setting these regs to that
> > first mute value to simplify things. I'll take another look at
> > eliminating this. As it is, it does not change the fact that the actual
> > reset value of 0xff is also mute from a user POV.
>
> If it is useful it definitely needs a comment explaining what's
> happening and that there's no practical change to the configuration. It
> would be nicer to be robust against the device getting a wider range of
> values in the register but that seems plausible.
I did some rework to make this unnecessary in v2.
Thanks,
Matt
Re: [PATCH 2/2] ASoC: add tda7419 audio processor driver
On Fri, Mar 09, 2018 at 03:29:12PM +, Mark Brown wrote:
> On Fri, Mar 09, 2018 at 09:35:48AM -0500, Matt Porter wrote:
> > On Wed, Feb 28, 2018 at 11:00:38AM +, Mark Brown wrote:
> > > On Tue, Feb 27, 2018 at 05:51:28PM -0500, Matt Porter wrote:
>
> > > > +static struct snd_kcontrol_new tda7419_controls[] = {
> > > > +SOC_ENUM("Main Source Select", soc_enum_main_src_sel),
>
> > > Should this be a DAPM route?
>
> > Ultimately yes. I initially took the path of ignoring DAPM support in
> > interests of getting some clean done. Is it ok to merge DAPM support
> > later or do you prefer just having it in the intitial driver? For
> > routes, it'll include Main/Second source selects, the Rear Source
> > switch, and Mix enable at least.
>
> You definitely shouldn't be implementing things that should be in DAPM
> as non-DAPM controls.
Ok, I addressed this by adding DAPM support in v2.
> > > > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_SUB_REG, 0xe0);
>
> > > This looks like it's setting default volumes - just leave those at the
> > > chip defaults and let userspace handle setting them, what works for one
> > > board may be totally inappropriate on another board and using the chip
> > > default means we've got some fixed thing we don't need to discuss.
>
> > This is actually setting the default/cache to the first mute value due
> > to the assumption in my implementation of the tda7419-specific get/set
> > for these registers. It simplified the code a bit to have these
> > initialized like this. e.g. for the attenuator group of registers,
> > x11x are all mute values, so 0xe0 is setting these regs to that
> > first mute value to simplify things. I'll take another look at
> > eliminating this. As it is, it does not change the fact that the actual
> > reset value of 0xff is also mute from a user POV.
>
> If it is useful it definitely needs a comment explaining what's
> happening and that there's no practical change to the configuration. It
> would be nicer to be robust against the device getting a wider range of
> values in the register but that seems plausible.
I did some rework to make this unnecessary in v2.
Thanks,
Matt
Re: [PATCH 1/2] ASoC: add tda7419 audio processor binding
On Mon, Mar 05, 2018 at 04:29:54PM -0600, Rob Herring wrote: > On Tue, Feb 27, 2018 at 05:51:27PM -0500, Matt Porter wrote: > > DeviceTree binding for the tda7419 audio processor. > > > > Signed-off-by: Matt Porter <mpor...@konsulko.com> > > --- > > Documentation/devicetree/bindings/sound/tda7419.txt | 15 +++ > > 1 file changed, 15 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt > > > > diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt > > b/Documentation/devicetree/bindings/sound/tda7419.txt > > new file mode 100644 > > index ..919318315600 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/sound/tda7419.txt > > @@ -0,0 +1,15 @@ > > +TDA7419 audio processor > > + > > +This device supports I2C only. > > + > > +Required properties: > > + > > +- compatible : "st,tda7419" > > +- reg : the I2C address of the device. > > For completeness: > > st,mute-gpios for MUTE pin? I'll add mute in as an optional property. > > vdd-supply? Yes, there's a required ~8.5V supply so I'll add the regulator reference. Thanks, Matt
Re: [PATCH 1/2] ASoC: add tda7419 audio processor binding
On Mon, Mar 05, 2018 at 04:29:54PM -0600, Rob Herring wrote: > On Tue, Feb 27, 2018 at 05:51:27PM -0500, Matt Porter wrote: > > DeviceTree binding for the tda7419 audio processor. > > > > Signed-off-by: Matt Porter > > --- > > Documentation/devicetree/bindings/sound/tda7419.txt | 15 +++ > > 1 file changed, 15 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt > > > > diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt > > b/Documentation/devicetree/bindings/sound/tda7419.txt > > new file mode 100644 > > index ..919318315600 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/sound/tda7419.txt > > @@ -0,0 +1,15 @@ > > +TDA7419 audio processor > > + > > +This device supports I2C only. > > + > > +Required properties: > > + > > +- compatible : "st,tda7419" > > +- reg : the I2C address of the device. > > For completeness: > > st,mute-gpios for MUTE pin? I'll add mute in as an optional property. > > vdd-supply? Yes, there's a required ~8.5V supply so I'll add the regulator reference. Thanks, Matt
Re: [PATCH 2/2] ASoC: add tda7419 audio processor driver
On Wed, Feb 28, 2018 at 11:00:38AM +, Mark Brown wrote:
> On Tue, Feb 27, 2018 at 05:51:28PM -0500, Matt Porter wrote:
>
> > +static bool tda7419_writeable_reg(struct device *dev, unsigned int reg)
> > +{
> > + return true;
> > +}
>
> This is the default behaviour, may as well omit it (but equally it does
> no harm).
Ok.
>
> > +static inline int tda7419_vol_get_value(int val, unsigned int mask,
> > + int thresh, unsigned int invert)
> > +{
> > + val &= mask;
> > + if (val < thresh) {
> > + if (invert)
> > + val = 0 - val;
> > + } else if (val > thresh) {
>
> This feels like something some other device might want to use so might
> warrant pulling out into a general control at some point but I'd not
> insist on doing it now.
Ok, yeah, I was also thinking it should be moved to a general helper
when the next user shows up. The most likely case is another part in
this family may have a similar register layout.
> > +static struct snd_kcontrol_new tda7419_controls[] = {
> > +SOC_ENUM("Main Source Select", soc_enum_main_src_sel),
>
> Should this be a DAPM route?
Ultimately yes. I initially took the path of ignoring DAPM support in
interests of getting some clean done. Is it ok to merge DAPM support
later or do you prefer just having it in the intitial driver? For
routes, it'll include Main/Second source selects, the Rear Source
switch, and Mix enable at least.
> > +SOC_SINGLE("Main Source AutoZero", TDA7419_MAIN_SRC_REG,
> > + TDA7419_MAIN_SRC_AUTOZERO, 1, 1),
>
> There's a lot of on/off switches for various things in here - these
> should all have Switch at the end of their names so that userspace can
> see how it's expected to display them. Most of the controls with a max
> value of 1 probably fall into this category.
I see. I'll fix that.
> > +SOC_SINGLE("Clock Fast Mode", TDA7419_MUTE_CLK_REG,
> > + TDA7419_CLK_FAST_MODE, 1, 1),
>
> What does this do - should it be in set_sysclk() or something?
This is where things get hazy, unfortunately. The datasheet is partially
garbage. So there's no description or guidance on clock management at
all. It's not clear what clock this is or what specifically "fast" does.
Because there's no concept of an external clock, the sysclk is clearly
internally generated. Because of the register labeling of clock
generator, it's probably sysclk but I'm not 100% sure what the relevance
is of fast mode. The working settings were divined from trial and error
as well a couple microcontroller projects scattered across the
interwebs.
On second look at this, I think I should at least remove this switch
and hard code it for now or move to set_sysclk(). I'm hesistant of the
latter because of the lack of information on this setting.
> > + /* Configure registers */
> > + regmap_write(tda7419->regmap, TDA7419_VOLUME_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_MIXING_GAIN_REG, 0x0f);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LF_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RF_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LR_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RR_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_MIXING_LEVEL_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_SUB_REG, 0xe0);
>
> This looks like it's setting default volumes - just leave those at the
> chip defaults and let userspace handle setting them, what works for one
> board may be totally inappropriate on another board and using the chip
> default means we've got some fixed thing we don't need to discuss.
This is actually setting the default/cache to the first mute value due
to the assumption in my implementation of the tda7419-specific get/set
for these registers. It simplified the code a bit to have these
initialized like this. e.g. for the attenuator group of registers,
x11x are all mute values, so 0xe0 is setting these regs to that
first mute value to simplify things. I'll take another look at
eliminating this. As it is, it does not change the fact that the actual
reset value of 0xff is also mute from a user POV.
> > +static int tda7419_remove(struct i2c_client *i2c)
> > +{
> > + int i;
> > + struct tda7419_data *tda7419 = i2c_get_clientdata(i2c);
> > +
> > + /* Reset registers to defaults */
> > + for (i = 0; i < ARRAY_SIZE(tda7419_regmap_defaults); i++)
> > + regmap_write(tda7419->regmap,
> > +tda7419_regmap_defaults[i].reg,
> > +tda7419_regmap_defaults[i].def);
>
> Why are we doing this? Other drivers don't do it... if anything I'd
> expect a reset on probe in case the bootloader or something left the
> chip configured.
Good point, I'll move this into probe. The part doesn't have a soft
reset provision so we need to do it manually like this.
-Matt
Re: [PATCH 2/2] ASoC: add tda7419 audio processor driver
On Wed, Feb 28, 2018 at 11:00:38AM +, Mark Brown wrote:
> On Tue, Feb 27, 2018 at 05:51:28PM -0500, Matt Porter wrote:
>
> > +static bool tda7419_writeable_reg(struct device *dev, unsigned int reg)
> > +{
> > + return true;
> > +}
>
> This is the default behaviour, may as well omit it (but equally it does
> no harm).
Ok.
>
> > +static inline int tda7419_vol_get_value(int val, unsigned int mask,
> > + int thresh, unsigned int invert)
> > +{
> > + val &= mask;
> > + if (val < thresh) {
> > + if (invert)
> > + val = 0 - val;
> > + } else if (val > thresh) {
>
> This feels like something some other device might want to use so might
> warrant pulling out into a general control at some point but I'd not
> insist on doing it now.
Ok, yeah, I was also thinking it should be moved to a general helper
when the next user shows up. The most likely case is another part in
this family may have a similar register layout.
> > +static struct snd_kcontrol_new tda7419_controls[] = {
> > +SOC_ENUM("Main Source Select", soc_enum_main_src_sel),
>
> Should this be a DAPM route?
Ultimately yes. I initially took the path of ignoring DAPM support in
interests of getting some clean done. Is it ok to merge DAPM support
later or do you prefer just having it in the intitial driver? For
routes, it'll include Main/Second source selects, the Rear Source
switch, and Mix enable at least.
> > +SOC_SINGLE("Main Source AutoZero", TDA7419_MAIN_SRC_REG,
> > + TDA7419_MAIN_SRC_AUTOZERO, 1, 1),
>
> There's a lot of on/off switches for various things in here - these
> should all have Switch at the end of their names so that userspace can
> see how it's expected to display them. Most of the controls with a max
> value of 1 probably fall into this category.
I see. I'll fix that.
> > +SOC_SINGLE("Clock Fast Mode", TDA7419_MUTE_CLK_REG,
> > + TDA7419_CLK_FAST_MODE, 1, 1),
>
> What does this do - should it be in set_sysclk() or something?
This is where things get hazy, unfortunately. The datasheet is partially
garbage. So there's no description or guidance on clock management at
all. It's not clear what clock this is or what specifically "fast" does.
Because there's no concept of an external clock, the sysclk is clearly
internally generated. Because of the register labeling of clock
generator, it's probably sysclk but I'm not 100% sure what the relevance
is of fast mode. The working settings were divined from trial and error
as well a couple microcontroller projects scattered across the
interwebs.
On second look at this, I think I should at least remove this switch
and hard code it for now or move to set_sysclk(). I'm hesistant of the
latter because of the lack of information on this setting.
> > + /* Configure registers */
> > + regmap_write(tda7419->regmap, TDA7419_VOLUME_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_MIXING_GAIN_REG, 0x0f);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LF_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RF_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LR_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RR_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_MIXING_LEVEL_REG, 0xe0);
> > + regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_SUB_REG, 0xe0);
>
> This looks like it's setting default volumes - just leave those at the
> chip defaults and let userspace handle setting them, what works for one
> board may be totally inappropriate on another board and using the chip
> default means we've got some fixed thing we don't need to discuss.
This is actually setting the default/cache to the first mute value due
to the assumption in my implementation of the tda7419-specific get/set
for these registers. It simplified the code a bit to have these
initialized like this. e.g. for the attenuator group of registers,
x11x are all mute values, so 0xe0 is setting these regs to that
first mute value to simplify things. I'll take another look at
eliminating this. As it is, it does not change the fact that the actual
reset value of 0xff is also mute from a user POV.
> > +static int tda7419_remove(struct i2c_client *i2c)
> > +{
> > + int i;
> > + struct tda7419_data *tda7419 = i2c_get_clientdata(i2c);
> > +
> > + /* Reset registers to defaults */
> > + for (i = 0; i < ARRAY_SIZE(tda7419_regmap_defaults); i++)
> > + regmap_write(tda7419->regmap,
> > +tda7419_regmap_defaults[i].reg,
> > +tda7419_regmap_defaults[i].def);
>
> Why are we doing this? Other drivers don't do it... if anything I'd
> expect a reset on probe in case the bootloader or something left the
> chip configured.
Good point, I'll move this into probe. The part doesn't have a soft
reset provision so we need to do it manually like this.
-Matt
[PATCH 1/2] ASoC: add tda7419 audio processor binding
DeviceTree binding for the tda7419 audio processor.
Signed-off-by: Matt Porter <mpor...@konsulko.com>
---
Documentation/devicetree/bindings/sound/tda7419.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt
diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt
b/Documentation/devicetree/bindings/sound/tda7419.txt
new file mode 100644
index ..919318315600
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tda7419.txt
@@ -0,0 +1,15 @@
+TDA7419 audio processor
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "st,tda7419"
+- reg : the I2C address of the device.
+
+Example:
+
+ap: tda7419@44 {
+ compatible = "st,tda7419";
+ reg = <0x44>;
+};
--
2.11.0
[PATCH 1/2] ASoC: add tda7419 audio processor binding
DeviceTree binding for the tda7419 audio processor.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/sound/tda7419.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt
diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt
b/Documentation/devicetree/bindings/sound/tda7419.txt
new file mode 100644
index ..919318315600
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tda7419.txt
@@ -0,0 +1,15 @@
+TDA7419 audio processor
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "st,tda7419"
+- reg : the I2C address of the device.
+
+Example:
+
+ap: tda7419@44 {
+ compatible = "st,tda7419";
+ reg = <0x44>;
+};
--
2.11.0
[PATCH 0/2] TDA7419 audio processor driver
This series adds an ASoC component driver for the ST TDA7419 audio processor which is commonly used in automotive audio applications. The datasheet can be found at http://www.st.com/resource/en/datasheet/tda7419.pdf Matt Porter (2): ASoC: add tda7419 audio processor binding ASoC: add tda7419 audio processor driver .../devicetree/bindings/sound/tda7419.txt | 15 + sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 571 + 4 files changed, 594 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt create mode 100644 sound/soc/codecs/tda7419.c -- 2.11.0
[PATCH 2/2] ASoC: add tda7419 audio processor driver
Component driver for the tda7419 audio processor. Signed-off-by: Matt Porter <mpor...@konsulko.com> --- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 571 + 3 files changed, 579 insertions(+) create mode 100644 sound/soc/codecs/tda7419.c diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 2b331f7266ab..1553cf2b9445 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -151,6 +151,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TAS571X if I2C select SND_SOC_TAS5720 if I2C select SND_SOC_TAS6424 if I2C + select SND_SOC_TDA7419 if I2C select SND_SOC_TFA9879 if I2C select SND_SOC_TLV320AIC23_I2C if I2C select SND_SOC_TLV320AIC23_SPI if SPI_MASTER @@ -910,6 +911,11 @@ config SND_SOC_TAS6424 Enable support for Texas Instruments TAS6424 high-efficiency digital input quad-channel Class-D audio power amplifiers. +config SND_SOC_TDA7419 + tristate "ST TDA7419 audio processor" + depends on I2C + select REGMAP_I2C + config SND_SOC_TFA9879 tristate "NXP Semiconductors TFA9879 amplifier" depends on I2C diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index da1571336f1e..6cf3c3b92cb5 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -160,6 +160,7 @@ snd-soc-tas5086-objs := tas5086.o snd-soc-tas571x-objs := tas571x.o snd-soc-tas5720-objs := tas5720.o snd-soc-tas6424-objs := tas6424.o +snd-soc-tda7419-objs := tda7419.o snd-soc-tfa9879-objs := tfa9879.o snd-soc-tlv320aic23-objs := tlv320aic23.o snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o @@ -405,6 +406,7 @@ obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o obj-$(CONFIG_SND_SOC_TAS5720) += snd-soc-tas5720.o obj-$(CONFIG_SND_SOC_TAS6424) += snd-soc-tas6424.o +obj-$(CONFIG_SND_SOC_TDA7419) += snd-soc-tda7419.o obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o diff --git a/sound/soc/codecs/tda7419.c b/sound/soc/codecs/tda7419.c new file mode 100644 index ..97a7d21b8f2a --- /dev/null +++ b/sound/soc/codecs/tda7419.c @@ -0,0 +1,571 @@ +/* + * TDA7419 audio processor driver + * + * Copyright 2018 Konsulko Group + * + * Author: Matt Porter <mpor...@konsulko.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define TDA7419_MAIN_SRC_REG 0x00 +#define TDA7419_LOUDNESS_REG 0x01 +#define TDA7419_MUTE_CLK_REG 0x02 +#define TDA7419_VOLUME_REG 0x03 +#define TDA7419_TREBLE_REG 0x04 +#define TDA7419_MIDDLE_REG 0x05 +#define TDA7419_BASS_REG 0x06 +#define TDA7419_SECOND_SRC_REG 0x07 +#define TDA7419_SUB_MID_BASS_REG 0x08 +#define TDA7419_MIXING_GAIN_REG0x09 +#define TDA7419_ATTENUATOR_LF_REG 0x0a +#define TDA7419_ATTENUATOR_RF_REG 0x0b +#define TDA7419_ATTENUATOR_LR_REG 0x0c +#define TDA7419_ATTENUATOR_RR_REG 0x0d +#define TDA7419_MIXING_LEVEL_REG 0x0e +#define TDA7419_ATTENUATOR_SUB_REG 0x0f +#define TDA7419_SA_CLK_AC_REG 0x10 +#define TDA7419_TESTING_REG0x11 + +#define TDA7419_MAIN_SRC_SEL 0 +#define TDA7419_MAIN_SRC_GAIN 3 +#define TDA7419_MAIN_SRC_AUTOZERO 7 + +#define TDA7419_LOUDNESS_ATTEN 0 +#define TDA7419_LOUDNESS_CENTER_FREQ 4 +#define TDA7419_LOUDNESS_BOOST 6 +#define TDA7419_LOUDNESS_SOFT_STEP 7 + +#define TDA7419_VOLUME_SOFT_STEP 7 + +#define TDA7419_SOFT_MUTE 0 +#define TDA7419_MUTE_INFLUENCE 1 +#define TDA7419_SOFT_MUTE_TIME 2 +#define TDA7419_SOFT_STEP_TIME 4 +#define TDA7419_CLK_FAST_MODE 7 + +#define TDA7419_TREBLE_CENTER_FREQ 5 +#define TDA7419_REF_OUT_SELECT 7 + +#define TDA7419_MIDDLE_Q_FACTOR5 +#define TDA7419_MIDDLE_SOFT_STEP 7 + +#define TDA7419_BASS_Q_FACTOR 5 +#define TDA7419_BASS_SOFT_STEP 7 + +#define TDA7419_SECOND_SRC_SEL 0 +#define TDA7419_SECOND_SRC_GAIN3 +#define TDA7419_REAR_SPKR_SRC 7 + +#define TDA7419_SUB_CUT_OFF_FREQ 0 +#define TDA7419_MIDDLE_CENTER_FREQ 2 +#define TDA7419_B
[PATCH 0/2] TDA7419 audio processor driver
This series adds an ASoC component driver for the ST TDA7419 audio processor which is commonly used in automotive audio applications. The datasheet can be found at http://www.st.com/resource/en/datasheet/tda7419.pdf Matt Porter (2): ASoC: add tda7419 audio processor binding ASoC: add tda7419 audio processor driver .../devicetree/bindings/sound/tda7419.txt | 15 + sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 571 + 4 files changed, 594 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tda7419.txt create mode 100644 sound/soc/codecs/tda7419.c -- 2.11.0
[PATCH 2/2] ASoC: add tda7419 audio processor driver
Component driver for the tda7419 audio processor. Signed-off-by: Matt Porter --- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda7419.c | 571 + 3 files changed, 579 insertions(+) create mode 100644 sound/soc/codecs/tda7419.c diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 2b331f7266ab..1553cf2b9445 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -151,6 +151,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TAS571X if I2C select SND_SOC_TAS5720 if I2C select SND_SOC_TAS6424 if I2C + select SND_SOC_TDA7419 if I2C select SND_SOC_TFA9879 if I2C select SND_SOC_TLV320AIC23_I2C if I2C select SND_SOC_TLV320AIC23_SPI if SPI_MASTER @@ -910,6 +911,11 @@ config SND_SOC_TAS6424 Enable support for Texas Instruments TAS6424 high-efficiency digital input quad-channel Class-D audio power amplifiers. +config SND_SOC_TDA7419 + tristate "ST TDA7419 audio processor" + depends on I2C + select REGMAP_I2C + config SND_SOC_TFA9879 tristate "NXP Semiconductors TFA9879 amplifier" depends on I2C diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index da1571336f1e..6cf3c3b92cb5 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -160,6 +160,7 @@ snd-soc-tas5086-objs := tas5086.o snd-soc-tas571x-objs := tas571x.o snd-soc-tas5720-objs := tas5720.o snd-soc-tas6424-objs := tas6424.o +snd-soc-tda7419-objs := tda7419.o snd-soc-tfa9879-objs := tfa9879.o snd-soc-tlv320aic23-objs := tlv320aic23.o snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o @@ -405,6 +406,7 @@ obj-$(CONFIG_SND_SOC_TAS5086) += snd-soc-tas5086.o obj-$(CONFIG_SND_SOC_TAS571X) += snd-soc-tas571x.o obj-$(CONFIG_SND_SOC_TAS5720) += snd-soc-tas5720.o obj-$(CONFIG_SND_SOC_TAS6424) += snd-soc-tas6424.o +obj-$(CONFIG_SND_SOC_TDA7419) += snd-soc-tda7419.o obj-$(CONFIG_SND_SOC_TFA9879) += snd-soc-tfa9879.o obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C) += snd-soc-tlv320aic23-i2c.o diff --git a/sound/soc/codecs/tda7419.c b/sound/soc/codecs/tda7419.c new file mode 100644 index ..97a7d21b8f2a --- /dev/null +++ b/sound/soc/codecs/tda7419.c @@ -0,0 +1,571 @@ +/* + * TDA7419 audio processor driver + * + * Copyright 2018 Konsulko Group + * + * Author: Matt Porter + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define TDA7419_MAIN_SRC_REG 0x00 +#define TDA7419_LOUDNESS_REG 0x01 +#define TDA7419_MUTE_CLK_REG 0x02 +#define TDA7419_VOLUME_REG 0x03 +#define TDA7419_TREBLE_REG 0x04 +#define TDA7419_MIDDLE_REG 0x05 +#define TDA7419_BASS_REG 0x06 +#define TDA7419_SECOND_SRC_REG 0x07 +#define TDA7419_SUB_MID_BASS_REG 0x08 +#define TDA7419_MIXING_GAIN_REG0x09 +#define TDA7419_ATTENUATOR_LF_REG 0x0a +#define TDA7419_ATTENUATOR_RF_REG 0x0b +#define TDA7419_ATTENUATOR_LR_REG 0x0c +#define TDA7419_ATTENUATOR_RR_REG 0x0d +#define TDA7419_MIXING_LEVEL_REG 0x0e +#define TDA7419_ATTENUATOR_SUB_REG 0x0f +#define TDA7419_SA_CLK_AC_REG 0x10 +#define TDA7419_TESTING_REG0x11 + +#define TDA7419_MAIN_SRC_SEL 0 +#define TDA7419_MAIN_SRC_GAIN 3 +#define TDA7419_MAIN_SRC_AUTOZERO 7 + +#define TDA7419_LOUDNESS_ATTEN 0 +#define TDA7419_LOUDNESS_CENTER_FREQ 4 +#define TDA7419_LOUDNESS_BOOST 6 +#define TDA7419_LOUDNESS_SOFT_STEP 7 + +#define TDA7419_VOLUME_SOFT_STEP 7 + +#define TDA7419_SOFT_MUTE 0 +#define TDA7419_MUTE_INFLUENCE 1 +#define TDA7419_SOFT_MUTE_TIME 2 +#define TDA7419_SOFT_STEP_TIME 4 +#define TDA7419_CLK_FAST_MODE 7 + +#define TDA7419_TREBLE_CENTER_FREQ 5 +#define TDA7419_REF_OUT_SELECT 7 + +#define TDA7419_MIDDLE_Q_FACTOR5 +#define TDA7419_MIDDLE_SOFT_STEP 7 + +#define TDA7419_BASS_Q_FACTOR 5 +#define TDA7419_BASS_SOFT_STEP 7 + +#define TDA7419_SECOND_SRC_SEL 0 +#define TDA7419_SECOND_SRC_GAIN3 +#define TDA7419_REAR_SPKR_SRC 7 + +#define TDA7419_SUB_CUT_OFF_FREQ 0 +#define TDA7419_MIDDLE_CENTER_FREQ 2 +#define TDA7419_BASS_CENTER_FREQ 4 +#define TDA7419_BASS_DC_MODE
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Sat, Aug 08, 2015 at 12:39:40PM +0100, Jonathan Cameron wrote:
> On 06/08/15 18:38, Matt Porter wrote:
> > On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
> >> On Mon, 3 Aug 2015, Matt Porter wrote:
> >
> > ...
> >
> >>> +static int max6675_read(struct max6675_state *st, int *val)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + ret = spi_read(st->spi, val, 2);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + /* Temperature is bits 14..3 */
> >>> + *val = (*val >> 3) & 0xfff;
> >>
> >> what about endianness conversion?
> >> use be16_to_cpu()
> >
> > Apologies, I spoke before engaging the brain on my first reply to this
> > As specified by the SPI subsystem docs, SPI buffers are always stored
> > in native endian order. There is no need for endianness conversion here.
> First of all, which doc say this?
> Secondly how does SPI know the endianness of the sensor which is what
> actually matters here? I2C can in theory make these guarantees as there
> is an expected byte order on the wire (even if quite a few drivers don't
> conform to the spec anyway). No such guarantee can exist for SPI.
include/linux/spi/spi.h:
* In-memory data values are always in native CPU byte order, translated
* from the wire byte order (big-endian except with SPI_LSB_FIRST). So
* for example when bits_per_word is sixteen, buffers are 2N bytes long
* (@len = 2N) and hold N sixteen bit words in CPU byte order.
So, as you mention, there's no standardized byte order but it's
controlled with the per transfer flag and big endian by default.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Sat, Aug 08, 2015 at 12:39:40PM +0100, Jonathan Cameron wrote:
On 06/08/15 18:38, Matt Porter wrote:
On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
On Mon, 3 Aug 2015, Matt Porter wrote:
...
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st-spi, val, 2);
+ if (ret 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val 3) 0xfff;
what about endianness conversion?
use be16_to_cpu()
Apologies, I spoke before engaging the brain on my first reply to this
As specified by the SPI subsystem docs, SPI buffers are always stored
in native endian order. There is no need for endianness conversion here.
First of all, which doc say this?
Secondly how does SPI know the endianness of the sensor which is what
actually matters here? I2C can in theory make these guarantees as there
is an expected byte order on the wire (even if quite a few drivers don't
conform to the spec anyway). No such guarantee can exist for SPI.
include/linux/spi/spi.h:
* In-memory data values are always in native CPU byte order, translated
* from the wire byte order (big-endian except with SPI_LSB_FIRST). So
* for example when bits_per_word is sixteen, buffers are 2N bytes long
* (@len = 2N) and hold N sixteen bit words in CPU byte order.
So, as you mention, there's no standardized byte order but it's
controlled with the per transfer flag and big endian by default.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
> On Mon, 3 Aug 2015, Matt Porter wrote:
...
> > +static int max6675_read(struct max6675_state *st, int *val)
> > +{
> > + int ret;
> > +
> > + ret = spi_read(st->spi, val, 2);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Temperature is bits 14..3 */
> > + *val = (*val >> 3) & 0xfff;
>
> what about endianness conversion?
> use be16_to_cpu()
Apologies, I spoke before engaging the brain on my first reply to this
As specified by the SPI subsystem docs, SPI buffers are always stored
in native endian order. There is no need for endianness conversion here.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
On Mon, 3 Aug 2015, Matt Porter wrote:
...
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st-spi, val, 2);
+ if (ret 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val 3) 0xfff;
what about endianness conversion?
use be16_to_cpu()
Apologies, I spoke before engaging the brain on my first reply to this
As specified by the SPI subsystem docs, SPI buffers are always stored
in native endian order. There is no need for endianness conversion here.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Wed, Aug 05, 2015 at 10:49:18AM +0200, Wolfram Sang wrote: > > > Yeah, we could start i2c.txt, probably better to have separate new > > patch all together. > > I will start such a file today as part of the i2c slave framework > update which introduces flags to the reg property. Will post to the i2c > list this week. > That sounds great, Wolfram, that will be a nice improvement for the binding docs. Thanks, Matt signature.asc Description: Digital signature
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Wed, Aug 05, 2015 at 12:04:25PM +0530, Vaibhav Hiremath wrote: > > > On Monday 27 July 2015 07:39 PM, Matt Porter wrote: > >On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote: > >>Driver will now supports enable/disable across msg xfer, which user > >>can control it by new DT property - > >> > >>i2c-disable-after-xfer : If set, driver will disable I2C module after msg > >> xfer and enable it back before xfer. > > > >If this is a new property specific to this Marvell part, it needs > >the vendor prefix as in mrvl,i2c-disable-after-xfer > > > > We discussed about this, I think in V1 or V2. Decided to use generic > name, as feature (in turn property) could be used by other drivers as > well. Ahh, ok, thanks...coming in too late on this one. :) > >Or, it couldn't hurt to start an i2c.txt for generic i2c bindings > >and store it there as this and others later in this series would > >reasonably apply to other controllers. > > > > Yeah, we could start i2c.txt, probably better to have separate new > patch all together. Great, yes, I've always found it hard to follow i2c generic bindings since they aren't defined in a clear place like other similar hardware (e.g. SPI). -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] MAX6675 IIO temperature driver
On Wed, Aug 05, 2015 at 11:33:25AM +0300, Daniel Baluta wrote: > On Tue, Aug 4, 2015 at 8:34 PM, Matt Porter wrote: > > On Tue, Aug 04, 2015 at 05:52:17PM +0100, Jonathan Cameron wrote: > >> > >> > >> On 3 August 2015 21:56:47 BST, Matt Porter wrote: > >> >This series adds a driver for the MAX6675 SPI thermocouple converter. > >> >The device supports temperature measurements via type-K thermocouples > >> >and implements cold-junction compensation within the part. The > >> >datasheet > >> >can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf > >> For a device like this where perhaps it's position wrt iio/hwmon boundary > >> is unclear > >> I want to see an argument for why IIO makes more sense in the cover letter > >> + cc > >> at least the hwmon MAINTAINERS if not the list... > > > > Will do. Just to summarize here, the typical use case for this type of > > thermocouple converter involves sample rates that are relatively high > > compared to what the hwmon interface can support. The upcoming hrtimer > > trigger will match up well with this to support fine-grained > > periodic samples. I'll add this in the v2 cover latter. > > Are we talking about this hrtimer trigger patches: > > http://marc.info/?l=linux-iio=143109196107382=2 > > Right? I've been busy with some other things, but I hope to have a > final version by Sunday :). That's it! Thanks. :) -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] MAX6675 IIO temperature driver
On Wed, Aug 05, 2015 at 11:33:25AM +0300, Daniel Baluta wrote: On Tue, Aug 4, 2015 at 8:34 PM, Matt Porter mpor...@konsulko.com wrote: On Tue, Aug 04, 2015 at 05:52:17PM +0100, Jonathan Cameron wrote: On 3 August 2015 21:56:47 BST, Matt Porter mpor...@konsulko.com wrote: This series adds a driver for the MAX6675 SPI thermocouple converter. The device supports temperature measurements via type-K thermocouples and implements cold-junction compensation within the part. The datasheet can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf For a device like this where perhaps it's position wrt iio/hwmon boundary is unclear I want to see an argument for why IIO makes more sense in the cover letter + cc at least the hwmon MAINTAINERS if not the list... Will do. Just to summarize here, the typical use case for this type of thermocouple converter involves sample rates that are relatively high compared to what the hwmon interface can support. The upcoming hrtimer trigger will match up well with this to support fine-grained periodic samples. I'll add this in the v2 cover latter. Are we talking about this hrtimer trigger patches: http://marc.info/?l=linux-iiom=143109196107382w=2 Right? I've been busy with some other things, but I hope to have a final version by Sunday :). That's it! Thanks. :) -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Wed, Aug 05, 2015 at 12:04:25PM +0530, Vaibhav Hiremath wrote: On Monday 27 July 2015 07:39 PM, Matt Porter wrote: On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote: Driver will now supports enable/disable across msg xfer, which user can control it by new DT property - i2c-disable-after-xfer : If set, driver will disable I2C module after msg xfer and enable it back before xfer. If this is a new property specific to this Marvell part, it needs the vendor prefix as in mrvl,i2c-disable-after-xfer We discussed about this, I think in V1 or V2. Decided to use generic name, as feature (in turn property) could be used by other drivers as well. Ahh, ok, thanks...coming in too late on this one. :) Or, it couldn't hurt to start an i2c.txt for generic i2c bindings and store it there as this and others later in this series would reasonably apply to other controllers. Yeah, we could start i2c.txt, probably better to have separate new patch all together. Great, yes, I've always found it hard to follow i2c generic bindings since they aren't defined in a clear place like other similar hardware (e.g. SPI). -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Wed, Aug 05, 2015 at 10:49:18AM +0200, Wolfram Sang wrote: Yeah, we could start i2c.txt, probably better to have separate new patch all together. I will start such a file today as part of the i2c slave framework update which introduces flags to the reg property. Will post to the i2c list this week. That sounds great, Wolfram, that will be a nice improvement for the binding docs. Thanks, Matt signature.asc Description: Digital signature
Re: [PATCH 0/3] MAX6675 IIO temperature driver
On Tue, Aug 04, 2015 at 05:52:17PM +0100, Jonathan Cameron wrote: > > > On 3 August 2015 21:56:47 BST, Matt Porter wrote: > >This series adds a driver for the MAX6675 SPI thermocouple converter. > >The device supports temperature measurements via type-K thermocouples > >and implements cold-junction compensation within the part. The > >datasheet > >can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf > For a device like this where perhaps it's position wrt iio/hwmon boundary is > unclear > I want to see an argument for why IIO makes more sense in the cover letter + > cc > at least the hwmon MAINTAINERS if not the list... Will do. Just to summarize here, the typical use case for this type of thermocouple converter involves sample rates that are relatively high compared to what the hwmon interface can support. The upcoming hrtimer trigger will match up well with this to support fine-grained periodic samples. I'll add this in the v2 cover latter. -Matt > >Matt Porter (3): > > iio: temperature: add max6675 dt binding > > iio: temperature: add max6675 thermocouple converter driver > > MAINTAINERS: add max6675 driver > > > > .../bindings/iio/temperature/max6675.txt | 19 +++ > > MAINTAINERS| 7 + > > drivers/iio/temperature/Kconfig| 11 ++ > > drivers/iio/temperature/Makefile | 1 + > >drivers/iio/temperature/max6675.c | 155 > >+ > > 5 files changed, 193 insertions(+) > >create mode 100644 > >Documentation/devicetree/bindings/iio/temperature/max6675.txt > > create mode 100644 drivers/iio/temperature/max6675.c > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Tue, Aug 04, 2015 at 11:30:36AM +0200, Paul Bolle wrote:
> On ma, 2015-08-03 at 16:56 -0400, Matt Porter wrote:
> > --- /dev/null
> > +++ b/drivers/iio/temperature/max6675.c
> > +static const struct spi_device_id max6675_spi_ids[] = {
> > + {"max6675", 0},
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(spi, max6675_spi_ids);
>
> > +MODULE_ALIAS("spi:max6675");
>
> For the "spi" alias this is "belt and suspenders":
> modinfo ./max6675.ko | grep alias
> alias: spi:max6675
> alias: acpi*:MXIM6675:*
> alias: of:N*T*Cmaxim,max6675*
> alias: spi:max6675
>
> I'd drop the MODULE_ALIAS().
Ok, given that it generates a redundant alias I'll drop it.
> (Mark Brown made it quite clear I shouldn't nag people about the origin
> of the various strings used in these module aliases. So I won't. But if
> you'd volunteer to explain me where "max6675" might come from for the
> spi alias that would, at least, satisfy my curiosity.)
Sure, one might hotplug in an entire SPI master and this SPI slave device
via any discoverable bus and need the alias to match the module. It's
also typically used in a board file on embedded x86 stuff where overriding
the DSDT is not desirable.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Tue, Aug 04, 2015 at 10:50:32AM +0300, Daniel Baluta wrote:
> On Mon, Aug 3, 2015 at 11:56 PM, Matt Porter wrote:
> > Add a driver for the MAX6675 thermocouple converter. This
> > device interfaces with K-type thermocouples and provides
> > cold-junction compensated temperature readings via a
> > SPI interface.
>
> ./scripts/checkpatch.pl --strict says:
>
> CHECK: braces {} should be used on all arms of this statement
> #118: FILE: drivers/iio/temperature/max6675.c:61:
Will address in v2, thanks.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Tue, Aug 04, 2015 at 11:30:36AM +0200, Paul Bolle wrote:
On ma, 2015-08-03 at 16:56 -0400, Matt Porter wrote:
--- /dev/null
+++ b/drivers/iio/temperature/max6675.c
+static const struct spi_device_id max6675_spi_ids[] = {
+ {max6675, 0},
+ {},
+};
+MODULE_DEVICE_TABLE(spi, max6675_spi_ids);
+MODULE_ALIAS(spi:max6675);
For the spi alias this is belt and suspenders:
modinfo ./max6675.ko | grep alias
alias: spi:max6675
alias: acpi*:MXIM6675:*
alias: of:N*T*Cmaxim,max6675*
alias: spi:max6675
I'd drop the MODULE_ALIAS().
Ok, given that it generates a redundant alias I'll drop it.
(Mark Brown made it quite clear I shouldn't nag people about the origin
of the various strings used in these module aliases. So I won't. But if
you'd volunteer to explain me where max6675 might come from for the
spi alias that would, at least, satisfy my curiosity.)
Sure, one might hotplug in an entire SPI master and this SPI slave device
via any discoverable bus and need the alias to match the module. It's
also typically used in a board file on embedded x86 stuff where overriding
the DSDT is not desirable.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Tue, Aug 04, 2015 at 10:50:32AM +0300, Daniel Baluta wrote:
On Mon, Aug 3, 2015 at 11:56 PM, Matt Porter mpor...@konsulko.com wrote:
Add a driver for the MAX6675 thermocouple converter. This
device interfaces with K-type thermocouples and provides
cold-junction compensated temperature readings via a
SPI interface.
./scripts/checkpatch.pl --strict says:
CHECK: braces {} should be used on all arms of this statement
#118: FILE: drivers/iio/temperature/max6675.c:61:
Will address in v2, thanks.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] MAX6675 IIO temperature driver
On Tue, Aug 04, 2015 at 05:52:17PM +0100, Jonathan Cameron wrote: On 3 August 2015 21:56:47 BST, Matt Porter mpor...@konsulko.com wrote: This series adds a driver for the MAX6675 SPI thermocouple converter. The device supports temperature measurements via type-K thermocouples and implements cold-junction compensation within the part. The datasheet can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf For a device like this where perhaps it's position wrt iio/hwmon boundary is unclear I want to see an argument for why IIO makes more sense in the cover letter + cc at least the hwmon MAINTAINERS if not the list... Will do. Just to summarize here, the typical use case for this type of thermocouple converter involves sample rates that are relatively high compared to what the hwmon interface can support. The upcoming hrtimer trigger will match up well with this to support fine-grained periodic samples. I'll add this in the v2 cover latter. -Matt Matt Porter (3): iio: temperature: add max6675 dt binding iio: temperature: add max6675 thermocouple converter driver MAINTAINERS: add max6675 driver .../bindings/iio/temperature/max6675.txt | 19 +++ MAINTAINERS| 7 + drivers/iio/temperature/Kconfig| 11 ++ drivers/iio/temperature/Makefile | 1 + drivers/iio/temperature/max6675.c | 155 + 5 files changed, 193 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/temperature/max6675.txt create mode 100644 drivers/iio/temperature/max6675.c -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
> On Mon, 3 Aug 2015, Matt Porter wrote:
>
> > Add a driver for the MAX6675 thermocouple converter. This
> > device interfaces with K-type thermocouples and provides
> > cold-junction compensated temperature readings via a
> > SPI interface.
>
> comments below
Thanks for the fast turnaround on the review! Will incorporate
the comments into v2 as noted below.
> > Signed-off-by: Matt Porter
> > ---
> > drivers/iio/temperature/Kconfig | 11 +++
> > drivers/iio/temperature/Makefile | 1 +
> > drivers/iio/temperature/max6675.c | 155
> > ++
> > 3 files changed, 167 insertions(+)
> > create mode 100644 drivers/iio/temperature/max6675.c
> >
> > diff --git a/drivers/iio/temperature/Kconfig
> > b/drivers/iio/temperature/Kconfig
> > index 21feaa4..b73fbf4 100644
> > --- a/drivers/iio/temperature/Kconfig
> > +++ b/drivers/iio/temperature/Kconfig
> > @@ -3,6 +3,17 @@
> > #
> > menu "Temperature sensors"
> >
> > +config MAX6675
> > + tristate "MAX6675 thermocouple converter"
> > + depends on SPI
> > + help
> > + If you say yes here you get support for the Maxim
> > + MAX6675 thermocouple converter connected with SPI.
> > +
> > + This driver can also be built as a module. If so, the module will
> > + be called max6675.
> > +
>
> extra newline
Ok
>
> > +
> > config MLX90614
> > tristate "MLX90614 contact-less infrared sensor"
> > depends on I2C
> > diff --git a/drivers/iio/temperature/Makefile
> > b/drivers/iio/temperature/Makefile
> > index 40710a8..d67ef40 100644
> > --- a/drivers/iio/temperature/Makefile
> > +++ b/drivers/iio/temperature/Makefile
> > @@ -2,5 +2,6 @@
> > # Makefile for industrial I/O temperature drivers
> > #
> >
> > +obj-$(CONFIG_MAX6675) += max6675.o
> > obj-$(CONFIG_MLX90614) += mlx90614.o
> > obj-$(CONFIG_TMP006) += tmp006.o
> > diff --git a/drivers/iio/temperature/max6675.c
> > b/drivers/iio/temperature/max6675.c
> > new file mode 100644
> > index 000..2d1fda2
> > --- /dev/null
> > +++ b/drivers/iio/temperature/max6675.c
> > @@ -0,0 +1,155 @@
> > +/*
> > + * max6675.c - MAX6675 thermocouple converter driver
> > + *
> > + * Copyright (C) 2015 Konsulko Group, Matt Porter
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct max6675_state {
> > + struct spi_device *spi;
> > +};
> > +
> > +static const struct iio_chan_spec max6675_channels[] = {
> > + {
> > + .type = IIO_TEMP,
> > + .info_mask_separate =
> > + BIT(IIO_CHAN_INFO_RAW) |
> > + BIT(IIO_CHAN_INFO_SCALE),
> > + },
> > +};
> > +
> > +static int max6675_read(struct max6675_state *st, int *val)
> > +{
> > + int ret;
> > +
> > + ret = spi_read(st->spi, val, 2);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Temperature is bits 14..3 */
> > + *val = (*val >> 3) & 0xfff;
>
> what about endianness conversion?
> use be16_to_cpu()
Ok, will fix.
> > +
> > + return ret;
> > +}
> > +
> > +static int max6675_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int *val,
> > + int *val2,
> > + long m)
> > +{
> > + struct max6675_state *st = iio_priv(indio_dev);
> > + int ret;
> > +
> > + if (m == IIO_CHAN_INFO_RAW) {
> > + *val2 = 0;
>
> no need to set *val2 to 0 when returning VAL_INT
Ok
>
> > + ret = max6675_read(st, val);
> > + if
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 03:39:00PM -0700, Matt Ranostay Matt Ranostay wrote:
> On Mon, Aug 3, 2015 at 1:56 PM, Matt Porter wrote:
...
> > +static int max6675_probe(struct spi_device *spi)
> > +{
> > + struct iio_dev *indio_dev;
> > + struct max6675_state *st;
> > + int ret = 0;
> > +
> > + indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> > + if (!indio_dev)
> > + return -ENOMEM;
> > +
> > + st = iio_priv(indio_dev);
> > + st->spi = spi;
> > +
> > + spi->mode = SPI_MODE_1;
> > + spi->bits_per_word = 16;
>
> Have this error or display a warning when it doesn't match the passed
> DT binding settings. Otherwise it may get confusing why other SPI
> modes and word sizes don't work.
Ok, good point. The only thing here is that I've specified that spi-cpha
is required in the binding, indicating that Mode 1 will be used. I need
this driver to be instantiated via three methods: ACPI, DT, and "board
file" so for the latter I'm hardcoding in the driver the mode. The
device only works in Mode 1 so this seems sane, it's not configurable.
I don't parse that mode from either DT or ACPI data since it's not
needed. About the only thing I could do is pedantically check for
spi-cpha and if not present complain..but I think it's fine to simply
not parse at all given that we've hardcoded this for the allowed mode.
There's no property for bits_per_word, it's configured on a per-transfer
basis. In this case, this configures the default to do a 16-bit transfer
as required by the device. There is no way to modify this by a client of
this driver.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] MAINTAINERS: add max6675 driver
Add myself as the MAX6675 driver maintainer. Signed-off-by: Matt Porter --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a226416..355cc09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6543,6 +6543,13 @@ S: Maintained F: Documentation/hwmon/max6650 F: drivers/hwmon/max6650.c +MAX6675 THERMOCOUPLE CONVERTER DRIVER +M: Matt Porter +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/temperature/max6675.txt +F: drivers/iio/temperature/max6675.c + MAX6697 HARDWARE MONITOR DRIVER M: Guenter Roeck L: lm-sens...@lm-sensors.org -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] iio: temperature: add max6675 dt binding
Add a DT binding for the MAX6675 SPI thermocouple converter.
The datasheet for this device may be found at
http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf
Signed-off-by: Matt Porter
---
.../devicetree/bindings/iio/temperature/max6675.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/temperature/max6675.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/max6675.txt
b/Documentation/devicetree/bindings/iio/temperature/max6675.txt
new file mode 100644
index 000..4e643e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/max6675.txt
@@ -0,0 +1,19 @@
+Maxim MAX6675 thermocouple converter
+
+Required properties:
+
+ - compatible: must be "maxim,max6675"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: must be 430
+ - spi-cpha: SPI Mode 1.
+
+ Refer to spi/spi-bus.txt for generic SPI slave bindings
+
+Example:
+
+ max6675@0 {
+ compatible = "maxim,max6675";
+ reg = <0>;
+ spi-max-frequency = <430>;
+ spi-cpha;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
Add a driver for the MAX6675 thermocouple converter. This
device interfaces with K-type thermocouples and provides
cold-junction compensated temperature readings via a
SPI interface.
Signed-off-by: Matt Porter
---
drivers/iio/temperature/Kconfig | 11 +++
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/max6675.c | 155 ++
3 files changed, 167 insertions(+)
create mode 100644 drivers/iio/temperature/max6675.c
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 21feaa4..b73fbf4 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -3,6 +3,17 @@
#
menu "Temperature sensors"
+config MAX6675
+ tristate "MAX6675 thermocouple converter"
+ depends on SPI
+ help
+ If you say yes here you get support for the Maxim
+ MAX6675 thermocouple converter connected with SPI.
+
+ This driver can also be built as a module. If so, the module will
+ be called max6675.
+
+
config MLX90614
tristate "MLX90614 contact-less infrared sensor"
depends on I2C
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index 40710a8..d67ef40 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -2,5 +2,6 @@
# Makefile for industrial I/O temperature drivers
#
+obj-$(CONFIG_MAX6675) += max6675.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_TMP006) += tmp006.o
diff --git a/drivers/iio/temperature/max6675.c
b/drivers/iio/temperature/max6675.c
new file mode 100644
index 000..2d1fda2
--- /dev/null
+++ b/drivers/iio/temperature/max6675.c
@@ -0,0 +1,155 @@
+/*
+ * max6675.c - MAX6675 thermocouple converter driver
+ *
+ * Copyright (C) 2015 Konsulko Group, Matt Porter
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct max6675_state {
+ struct spi_device *spi;
+};
+
+static const struct iio_chan_spec max6675_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st->spi, val, 2);
+ if (ret < 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val >> 3) & 0xfff;
+
+ return ret;
+}
+
+static int max6675_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
+{
+ struct max6675_state *st = iio_priv(indio_dev);
+ int ret;
+
+ if (m == IIO_CHAN_INFO_RAW) {
+ *val2 = 0;
+ ret = max6675_read(st, val);
+ if (ret)
+ return ret;
+ } else if (m == IIO_CHAN_INFO_SCALE) {
+ *val = 250;
+ *val2 = 0;
+ } else
+ return -EINVAL;
+
+ return IIO_VAL_INT;
+}
+
+static const struct iio_info max6675_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = _read_raw,
+};
+
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
+
+ indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st->spi = spi;
+
+ spi->mode = SPI_MODE_1;
+ spi->bits_per_word = 16;
+
+ spi_set_drvdata(spi, indio_dev);
+
+ indio_dev->dev.parent = >dev;
+ indio_dev->name = spi_get_device_id(spi)->name;
+ indio_dev->channels = max6675_channels;
+ indio_dev->num_channels = ARRAY_SIZE(max6675_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->info = _info;
+
+ ret = iio_device_register(indio_dev);
+ if (ret < 0)
+ dev_err(>dev, "unable to register device\n");
+
+ return ret;
+}
+
+static int max6675_remove(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev = spi_get_drvdata(spi);
+
+ iio_device_unregister(indio_dev);
+
+ return 0;
+}
+
+static const struct acpi_dev
[PATCH 0/3] MAX6675 IIO temperature driver
This series adds a driver for the MAX6675 SPI thermocouple converter. The device supports temperature measurements via type-K thermocouples and implements cold-junction compensation within the part. The datasheet can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf Matt Porter (3): iio: temperature: add max6675 dt binding iio: temperature: add max6675 thermocouple converter driver MAINTAINERS: add max6675 driver .../bindings/iio/temperature/max6675.txt | 19 +++ MAINTAINERS| 7 + drivers/iio/temperature/Kconfig| 11 ++ drivers/iio/temperature/Makefile | 1 + drivers/iio/temperature/max6675.c | 155 + 5 files changed, 193 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/temperature/max6675.txt create mode 100644 drivers/iio/temperature/max6675.c -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
On Mon, 3 Aug 2015, Matt Porter wrote:
Add a driver for the MAX6675 thermocouple converter. This
device interfaces with K-type thermocouples and provides
cold-junction compensated temperature readings via a
SPI interface.
comments below
Thanks for the fast turnaround on the review! Will incorporate
the comments into v2 as noted below.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
drivers/iio/temperature/Kconfig | 11 +++
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/max6675.c | 155
++
3 files changed, 167 insertions(+)
create mode 100644 drivers/iio/temperature/max6675.c
diff --git a/drivers/iio/temperature/Kconfig
b/drivers/iio/temperature/Kconfig
index 21feaa4..b73fbf4 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -3,6 +3,17 @@
#
menu Temperature sensors
+config MAX6675
+ tristate MAX6675 thermocouple converter
+ depends on SPI
+ help
+ If you say yes here you get support for the Maxim
+ MAX6675 thermocouple converter connected with SPI.
+
+ This driver can also be built as a module. If so, the module will
+ be called max6675.
+
extra newline
Ok
+
config MLX90614
tristate MLX90614 contact-less infrared sensor
depends on I2C
diff --git a/drivers/iio/temperature/Makefile
b/drivers/iio/temperature/Makefile
index 40710a8..d67ef40 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -2,5 +2,6 @@
# Makefile for industrial I/O temperature drivers
#
+obj-$(CONFIG_MAX6675) += max6675.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_TMP006) += tmp006.o
diff --git a/drivers/iio/temperature/max6675.c
b/drivers/iio/temperature/max6675.c
new file mode 100644
index 000..2d1fda2
--- /dev/null
+++ b/drivers/iio/temperature/max6675.c
@@ -0,0 +1,155 @@
+/*
+ * max6675.c - MAX6675 thermocouple converter driver
+ *
+ * Copyright (C) 2015 Konsulko Group, Matt Porter mpor...@konsulko.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/acpi.h
+#include linux/init.h
+#include linux/module.h
+#include linux/of.h
+#include linux/iio/iio.h
+#include linux/spi/spi.h
+
+struct max6675_state {
+ struct spi_device *spi;
+};
+
+static const struct iio_chan_spec max6675_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st-spi, val, 2);
+ if (ret 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val 3) 0xfff;
what about endianness conversion?
use be16_to_cpu()
Ok, will fix.
+
+ return ret;
+}
+
+static int max6675_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
+{
+ struct max6675_state *st = iio_priv(indio_dev);
+ int ret;
+
+ if (m == IIO_CHAN_INFO_RAW) {
+ *val2 = 0;
no need to set *val2 to 0 when returning VAL_INT
Ok
+ ret = max6675_read(st, val);
+ if (ret)
+ return ret;
+ } else if (m == IIO_CHAN_INFO_SCALE) {
+ *val = 250;
+ *val2 = 0;
+ } else
+ return -EINVAL;
+
+ return IIO_VAL_INT;
+}
+
+static const struct iio_info max6675_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = max6675_read_raw,
+};
+
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
no need to initialize ret
Ok
+
+ indio_dev = devm_iio_device_alloc(spi-dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st-spi = spi;
+
+ spi-mode = SPI_MODE_1;
+ spi-bits_per_word = 16;
+
+ spi_set_drvdata(spi, indio_dev);
+
+ indio_dev-dev.parent = spi-dev;
+ indio_dev-name = spi_get_device_id(spi)-name;
+ indio_dev-channels = max6675_channels
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 03:39:00PM -0700, Matt Ranostay Matt Ranostay wrote:
On Mon, Aug 3, 2015 at 1:56 PM, Matt Porter mpor...@konsulko.com wrote:
...
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
+
+ indio_dev = devm_iio_device_alloc(spi-dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st-spi = spi;
+
+ spi-mode = SPI_MODE_1;
+ spi-bits_per_word = 16;
Have this error or display a warning when it doesn't match the passed
DT binding settings. Otherwise it may get confusing why other SPI
modes and word sizes don't work.
Ok, good point. The only thing here is that I've specified that spi-cpha
is required in the binding, indicating that Mode 1 will be used. I need
this driver to be instantiated via three methods: ACPI, DT, and board
file so for the latter I'm hardcoding in the driver the mode. The
device only works in Mode 1 so this seems sane, it's not configurable.
I don't parse that mode from either DT or ACPI data since it's not
needed. About the only thing I could do is pedantically check for
spi-cpha and if not present complain..but I think it's fine to simply
not parse at all given that we've hardcoded this for the allowed mode.
There's no property for bits_per_word, it's configured on a per-transfer
basis. In this case, this configures the default to do a 16-bit transfer
as required by the device. There is no way to modify this by a client of
this driver.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] iio: temperature: add max6675 dt binding
Add a DT binding for the MAX6675 SPI thermocouple converter.
The datasheet for this device may be found at
http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf
Signed-off-by: Matt Porter mpor...@konsulko.com
---
.../devicetree/bindings/iio/temperature/max6675.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/temperature/max6675.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/max6675.txt
b/Documentation/devicetree/bindings/iio/temperature/max6675.txt
new file mode 100644
index 000..4e643e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/max6675.txt
@@ -0,0 +1,19 @@
+Maxim MAX6675 thermocouple converter
+
+Required properties:
+
+ - compatible: must be maxim,max6675
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: must be 430
+ - spi-cpha: SPI Mode 1.
+
+ Refer to spi/spi-bus.txt for generic SPI slave bindings
+
+Example:
+
+ max6675@0 {
+ compatible = maxim,max6675;
+ reg = 0;
+ spi-max-frequency = 430;
+ spi-cpha;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
Add a driver for the MAX6675 thermocouple converter. This
device interfaces with K-type thermocouples and provides
cold-junction compensated temperature readings via a
SPI interface.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
drivers/iio/temperature/Kconfig | 11 +++
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/max6675.c | 155 ++
3 files changed, 167 insertions(+)
create mode 100644 drivers/iio/temperature/max6675.c
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 21feaa4..b73fbf4 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -3,6 +3,17 @@
#
menu Temperature sensors
+config MAX6675
+ tristate MAX6675 thermocouple converter
+ depends on SPI
+ help
+ If you say yes here you get support for the Maxim
+ MAX6675 thermocouple converter connected with SPI.
+
+ This driver can also be built as a module. If so, the module will
+ be called max6675.
+
+
config MLX90614
tristate MLX90614 contact-less infrared sensor
depends on I2C
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index 40710a8..d67ef40 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -2,5 +2,6 @@
# Makefile for industrial I/O temperature drivers
#
+obj-$(CONFIG_MAX6675) += max6675.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_TMP006) += tmp006.o
diff --git a/drivers/iio/temperature/max6675.c
b/drivers/iio/temperature/max6675.c
new file mode 100644
index 000..2d1fda2
--- /dev/null
+++ b/drivers/iio/temperature/max6675.c
@@ -0,0 +1,155 @@
+/*
+ * max6675.c - MAX6675 thermocouple converter driver
+ *
+ * Copyright (C) 2015 Konsulko Group, Matt Porter mpor...@konsulko.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/acpi.h
+#include linux/init.h
+#include linux/module.h
+#include linux/of.h
+#include linux/iio/iio.h
+#include linux/spi/spi.h
+
+struct max6675_state {
+ struct spi_device *spi;
+};
+
+static const struct iio_chan_spec max6675_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st-spi, val, 2);
+ if (ret 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val 3) 0xfff;
+
+ return ret;
+}
+
+static int max6675_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
+{
+ struct max6675_state *st = iio_priv(indio_dev);
+ int ret;
+
+ if (m == IIO_CHAN_INFO_RAW) {
+ *val2 = 0;
+ ret = max6675_read(st, val);
+ if (ret)
+ return ret;
+ } else if (m == IIO_CHAN_INFO_SCALE) {
+ *val = 250;
+ *val2 = 0;
+ } else
+ return -EINVAL;
+
+ return IIO_VAL_INT;
+}
+
+static const struct iio_info max6675_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = max6675_read_raw,
+};
+
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
+
+ indio_dev = devm_iio_device_alloc(spi-dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st-spi = spi;
+
+ spi-mode = SPI_MODE_1;
+ spi-bits_per_word = 16;
+
+ spi_set_drvdata(spi, indio_dev);
+
+ indio_dev-dev.parent = spi-dev;
+ indio_dev-name = spi_get_device_id(spi)-name;
+ indio_dev-channels = max6675_channels;
+ indio_dev-num_channels = ARRAY_SIZE(max6675_channels);
+ indio_dev-modes = INDIO_DIRECT_MODE;
+ indio_dev-info = max6675_info;
+
+ ret = iio_device_register(indio_dev);
+ if (ret 0)
+ dev_err(spi-dev, unable to register device\n);
+
+ return ret;
+}
+
+static int max6675_remove(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev = spi_get_drvdata(spi);
+
+ iio_device_unregister(indio_dev);
+
+ return 0;
+}
+
+static const struct
[PATCH 0/3] MAX6675 IIO temperature driver
This series adds a driver for the MAX6675 SPI thermocouple converter. The device supports temperature measurements via type-K thermocouples and implements cold-junction compensation within the part. The datasheet can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf Matt Porter (3): iio: temperature: add max6675 dt binding iio: temperature: add max6675 thermocouple converter driver MAINTAINERS: add max6675 driver .../bindings/iio/temperature/max6675.txt | 19 +++ MAINTAINERS| 7 + drivers/iio/temperature/Kconfig| 11 ++ drivers/iio/temperature/Makefile | 1 + drivers/iio/temperature/max6675.c | 155 + 5 files changed, 193 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/temperature/max6675.txt create mode 100644 drivers/iio/temperature/max6675.c -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] MAINTAINERS: add max6675 driver
Add myself as the MAX6675 driver maintainer. Signed-off-by: Matt Porter mpor...@konsulko.com --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a226416..355cc09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6543,6 +6543,13 @@ S: Maintained F: Documentation/hwmon/max6650 F: drivers/hwmon/max6650.c +MAX6675 THERMOCOUPLE CONVERTER DRIVER +M: Matt Porter mpor...@konsulko.com +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/temperature/max6675.txt +F: drivers/iio/temperature/max6675.c + MAX6697 HARDWARE MONITOR DRIVER M: Guenter Roeck li...@roeck-us.net L: lm-sens...@lm-sensors.org -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Tue, Jul 28, 2015 at 10:47:28AM +0200, Teresa Remmet wrote:
> Hello Igor,
>
> Am Dienstag, den 28.07.2015, 11:29 +0300 schrieb Igor Grinberg:
> > Hi Matt,
> >
> > On 07/27/15 17:34, Matt Porter wrote:
> > > On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
> > >> phyCORE-AM335x is a SoM (System on Module) containing
> > >> a AM335x SOC. The module can be connected to different
> > >> carrier boards.
> > >>
> > >> Some hardware parts are configurable on the phyCORE-AM335x.
> > >> So they are disabled on default in this som dtsi file.
> > >> They will be enabled in the board dts files, when populated.
> > >>
> > >> * RAM up to 1GiB
> > >> * PMIC
> > >> * NAND flash up to 1GiB
> > >> * Eth PHY on SOM: 1x RMII
> > >> * SPI NOR flash 8MiB (optional)
> > >> * i2c RTC (optional)
> > >> * i2c EEPROM 4kiB (optional)
> > >>
> > >> Signed-off-by: Teresa Remmet
> > >> ---
> > >> arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
> > >> ++
> > >> 1 file changed, 368 insertions(+)
> > >> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
> > >>
> > >> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> > >> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> > >> new file mode 100644
> > >> index 000..4d28fc3
> > >> --- /dev/null
> > >> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> >
> > [...]
> >
> > >> +#include "am33xx.dtsi"
> > >> +
> > >> +/ {
> > >> +model = "Phytec AM335x phyCORE";
> > >> +compatible = "phytec,am335x-phycore-som", "ti,am33xx";
> > >
> > > One minor thing here...wildcards in compatible strings aren't permitted.
> > > However, family compatibles like "ti,am33xx" that came in before this
> > > was enforced are grandfathered. Ideally, the newly introced board/som
> > > specific strings should not propagate that wildcard. i.e. something
> > > like "phytec,am3352-phycore-som" or whatever is the base family part
> > > on these SOMs.
> > >
> >
> > I'm not sure this is wild card.
> > I tend to think that it is the real name of the som [1], no?
> >
> > http://phytec.com/products/system-on-modules/phycore/am335x/
>
> Yes, your right. This is the name of the SoM. The phyCORE may have
> different am335x versions mounted. So there is not the one am3352 or
> am3359 always used.
Ok, great. Disregard then.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Tue, Jul 28, 2015 at 10:47:28AM +0200, Teresa Remmet wrote:
Hello Igor,
Am Dienstag, den 28.07.2015, 11:29 +0300 schrieb Igor Grinberg:
Hi Matt,
On 07/27/15 17:34, Matt Porter wrote:
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
phyCORE-AM335x is a SoM (System on Module) containing
a AM335x SOC. The module can be connected to different
carrier boards.
Some hardware parts are configurable on the phyCORE-AM335x.
So they are disabled on default in this som dtsi file.
They will be enabled in the board dts files, when populated.
* RAM up to 1GiB
* PMIC
* NAND flash up to 1GiB
* Eth PHY on SOM: 1x RMII
* SPI NOR flash 8MiB (optional)
* i2c RTC (optional)
* i2c EEPROM 4kiB (optional)
Signed-off-by: Teresa Remmet t.rem...@phytec.de
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
++
1 file changed, 368 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..4d28fc3
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
[...]
+#include am33xx.dtsi
+
+/ {
+model = Phytec AM335x phyCORE;
+compatible = phytec,am335x-phycore-som, ti,am33xx;
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like ti,am33xx that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like phytec,am3352-phycore-som or whatever is the base family part
on these SOMs.
I'm not sure this is wild card.
I tend to think that it is the real name of the som [1], no?
http://phytec.com/products/system-on-modules/phycore/am335x/
Yes, your right. This is the name of the SoM. The phyCORE may have
different am335x versions mounted. So there is not the one am3352 or
am3359 always used.
Ok, great. Disregard then.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
> phyCORE-AM335x is a SoM (System on Module) containing
> a AM335x SOC. The module can be connected to different
> carrier boards.
>
> Some hardware parts are configurable on the phyCORE-AM335x.
> So they are disabled on default in this som dtsi file.
> They will be enabled in the board dts files, when populated.
>
> * RAM up to 1GiB
> * PMIC
> * NAND flash up to 1GiB
> * Eth PHY on SOM: 1x RMII
> * SPI NOR flash 8MiB (optional)
> * i2c RTC (optional)
> * i2c EEPROM 4kiB (optional)
>
> Signed-off-by: Teresa Remmet
> ---
> arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
> ++
> 1 file changed, 368 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
>
> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> new file mode 100644
> index 000..4d28fc3
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> @@ -0,0 +1,368 @@
> +/*
> + * Copyright (C) 2015 Phytec Messtechnik GmbH
> + * Author: Teresa Remmet
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "Phytec AM335x phyCORE";
> + compatible = "phytec,am335x-phycore-som", "ti,am33xx";
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like "ti,am33xx" that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like "phytec,am3352-phycore-som" or whatever is the base family part
on these SOMs.
-Matt
> +
> + aliases {
> + rtc0 = _rtc;
> + rtc1 =
> + };
> +
> + cpus {
> + cpu@0 {
> + cpu0-supply = <_reg>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +
> + vbat: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + };
> +};
> +
> +/* Crypto Module */
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +/* Ethernet */
> +_pinmux {
> + ethernet0_pins: pinmux_ethernet0 {
> + pinctrl-single,pins = <
> + 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_crs.rmii1_crs_dv */
> + 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxerr.rmii1_rxerr */
> + 0x114 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txen.rmii1_txen */
> + 0x124 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd1.rmii1_txd1 */
> + 0x128 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd0.rmii1_txd0 */
> + 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd1.rmii1_rxd1 */
> + 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd0.rmii1_rxd0 */
> + 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
> rmii1_refclk.rmii1_refclk */
> + >;
> + };
> +
> + mdio_pins: pinmux_mdio {
> + pinctrl-single,pins = <
> + /* MDIO */
> + 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
> /* mdio_data.mdio_data */
> + 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
> /* mdio_clk.mdio_clk */
> + >;
> + };
> +};
> +
> +_emac0 {
> + phy_id = <_mdio>, <0>;
> + phy-mode = "rmii";
> + dual_emac_res_vlan = <1>;
> +};
> +
> +_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +};
> +
> + {
> + slaves = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +};
> +
> +_sel {
> + rmii-clock-ext;
> +};
> +
> +/* I2C Busses */
> +_pinmux {
> + i2c0_pins: pinmux_i2c0 {
> + pinctrl-single,pins = <
> + 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
> + 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
> + >;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + clock-frequency = <40>;
> + status = "okay";
> +
> + tps: pmic@2d {
> + reg = <0x2d>;
> + };
> +
> + i2c_eeprom: eeprom@52 {
> + compatible = "atmel,24c32";
> + pagesize = <32>;
> + reg = <0x52>;
> + status = "disabled";
> + };
> +
> + i2c_rtc: rtc@68 {
> + compatible = "rv4162";
> + reg = <0x68>;
> + status = "disabled";
> + };
> +};
> +
> +/* NAND memory */
> +_pinmux {
> + nandflash_pins: pinmux_nandflash {
> +
Re: [PATCH-v5 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:05PM +0530, Vaibhav Hiremath wrote:
> With addition of PXA910 family of devices, the TWSI module supports
> new feature which allows us to adjust SCLK. i2c-pxa driver takes input
> configuration in nsec and converts it to respective bit-fields,
>
> - i2c-sclk-low-time-ns : SCLK low time (tlow)
>This property is used along with mode selection.
> - i2c-sclk-high-time-ns : SCLK high time (thigh)
> - i2c-start-hold-time-ns : Used in case of high speed mode for start bit
>hold/setup wait counter.
> - i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
>hold/setup wait counter.
> - i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
>standard and fast mode.
Again, these should have a mrvl prefix..very specific to this PXA
controller.
-Matt
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 9657db5..bb4df60 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -23,12 +23,25 @@ Optional properties :
> - i2c-disable-after-xfer : If set, driver will disable I2C module
> after msg xfer and enable it again before xfer.
>
> + (Applicable to PXA910 family):
> +
> + - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high
> + speed mode.
> + This property is used along with mode selection. Driver uses this property
> + to set low/high time for standard and fast speed mode, as HW counter
> + bit-field is same for both.
> + - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed
> + mode only.
> +
> Examples:
> twsi1: i2c@d4011000 {
> compatible = "mrvl,mmp-twsi";
> reg = <0xd4011000 0x1000>;
> interrupts = <7>;
> mrvl,i2c-fast-mode;
> +
> + i2c-sclk-low-time-ns = <988>;
> + i2c-sclk-high-time-ns = <988>;
> };
>
> twsi2: i2c@d4025000 {
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote:
> Driver will now supports enable/disable across msg xfer, which user
> can control it by new DT property -
>
> i2c-disable-after-xfer : If set, driver will disable I2C module after msg
> xfer and enable it back before xfer.
If this is a new property specific to this Marvell part, it needs
the vendor prefix as in mrvl,i2c-disable-after-xfer
Or, it couldn't hurt to start an i2c.txt for generic i2c bindings
and store it there as this and others later in this series would
reasonably apply to other controllers.
-Matt
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 12b78ac..9657db5 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -18,6 +18,11 @@ Recommended properties :
> status register of i2c controller instead.
> - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
>
> +Optional properties :
> +
> + - i2c-disable-after-xfer : If set, driver will disable I2C module
> + after msg xfer and enable it again before xfer.
> +
> Examples:
> twsi1: i2c@d4011000 {
> compatible = "mrvl,mmp-twsi";
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
phyCORE-AM335x is a SoM (System on Module) containing
a AM335x SOC. The module can be connected to different
carrier boards.
Some hardware parts are configurable on the phyCORE-AM335x.
So they are disabled on default in this som dtsi file.
They will be enabled in the board dts files, when populated.
* RAM up to 1GiB
* PMIC
* NAND flash up to 1GiB
* Eth PHY on SOM: 1x RMII
* SPI NOR flash 8MiB (optional)
* i2c RTC (optional)
* i2c EEPROM 4kiB (optional)
Signed-off-by: Teresa Remmet t.rem...@phytec.de
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
++
1 file changed, 368 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..4d28fc3
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,368 @@
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet t.rem...@phytec.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include am33xx.dtsi
+
+/ {
+ model = Phytec AM335x phyCORE;
+ compatible = phytec,am335x-phycore-som, ti,am33xx;
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like ti,am33xx that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like phytec,am3352-phycore-som or whatever is the base family part
on these SOMs.
-Matt
+
+ aliases {
+ rtc0 = i2c_rtc;
+ rtc1 = rtc;
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ };
+};
+
+/* Crypto Module */
+aes {
+ status = okay;
+};
+
+sham {
+ status = okay;
+};
+
+/* Ethernet */
+am33xx_pinmux {
+ ethernet0_pins: pinmux_ethernet0 {
+ pinctrl-single,pins =
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_crs.rmii1_crs_dv */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxerr.rmii1_rxerr */
+ 0x114 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txen.rmii1_txen */
+ 0x124 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd1.rmii1_txd1 */
+ 0x128 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd0.rmii1_txd0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd1.rmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd0.rmii1_rxd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
rmii1_refclk.rmii1_refclk */
+ ;
+ };
+
+ mdio_pins: pinmux_mdio {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 0;
+ phy-mode = rmii;
+ dual_emac_res_vlan = 1;
+};
+
+davinci_mdio {
+ pinctrl-names = default;
+ pinctrl-0 = mdio_pins;
+ status = okay;
+};
+
+mac {
+ slaves = 1;
+ pinctrl-names = default;
+ pinctrl-0 = ethernet0_pins;
+ status = okay;
+};
+
+phy_sel {
+ rmii-clock-ext;
+};
+
+/* I2C Busses */
+am33xx_pinmux {
+ i2c0_pins: pinmux_i2c0 {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ ;
+ };
+};
+
+i2c0 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+ status = okay;
+
+ tps: pmic@2d {
+ reg = 0x2d;
+ };
+
+ i2c_eeprom: eeprom@52 {
+ compatible = atmel,24c32;
+ pagesize = 32;
+ reg = 0x52;
+ status = disabled;
+ };
+
+ i2c_rtc: rtc@68 {
+ compatible = rv4162;
+ reg = 0x68;
+ status = disabled;
+ };
+};
+
+/* NAND memory */
+am33xx_pinmux {
+ nandflash_pins: pinmux_nandflash {
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote:
Driver will now supports enable/disable across msg xfer, which user
can control it by new DT property -
i2c-disable-after-xfer : If set, driver will disable I2C module after msg
xfer and enable it back before xfer.
If this is a new property specific to this Marvell part, it needs
the vendor prefix as in mrvl,i2c-disable-after-xfer
Or, it couldn't hurt to start an i2c.txt for generic i2c bindings
and store it there as this and others later in this series would
reasonably apply to other controllers.
-Matt
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..9657db5 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -18,6 +18,11 @@ Recommended properties :
status register of i2c controller instead.
- mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
+Optional properties :
+
+ - i2c-disable-after-xfer : If set, driver will disable I2C module
+ after msg xfer and enable it again before xfer.
+
Examples:
twsi1: i2c@d4011000 {
compatible = mrvl,mmp-twsi;
--
1.9.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v5 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:05PM +0530, Vaibhav Hiremath wrote:
With addition of PXA910 family of devices, the TWSI module supports
new feature which allows us to adjust SCLK. i2c-pxa driver takes input
configuration in nsec and converts it to respective bit-fields,
- i2c-sclk-low-time-ns : SCLK low time (tlow)
This property is used along with mode selection.
- i2c-sclk-high-time-ns : SCLK high time (thigh)
- i2c-start-hold-time-ns : Used in case of high speed mode for start bit
hold/setup wait counter.
- i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
hold/setup wait counter.
- i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
standard and fast mode.
Again, these should have a mrvl prefix..very specific to this PXA
controller.
-Matt
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 9657db5..bb4df60 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -23,12 +23,25 @@ Optional properties :
- i2c-disable-after-xfer : If set, driver will disable I2C module
after msg xfer and enable it again before xfer.
+ (Applicable to PXA910 family):
+
+ - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high
+ speed mode.
+ This property is used along with mode selection. Driver uses this property
+ to set low/high time for standard and fast speed mode, as HW counter
+ bit-field is same for both.
+ - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed
+ mode only.
+
Examples:
twsi1: i2c@d4011000 {
compatible = mrvl,mmp-twsi;
reg = 0xd4011000 0x1000;
interrupts = 7;
mrvl,i2c-fast-mode;
+
+ i2c-sclk-low-time-ns = 988;
+ i2c-sclk-high-time-ns = 988;
};
twsi2: i2c@d4025000 {
--
1.9.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
On Tue, Apr 14, 2015 at 10:36:15AM -0500, Rob Herring wrote: > On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank > wrote: > > In recent years there have been proposed tools to aid in the creation of > > valid > > device trees and in debugging device tree issues. An example of this is the > > various approaches proposed (with source code provided) to validate device > > tree > > source against valid bindings. As of today, device tree related tools, > > techniques, and debugging infrastructure have not progressed very far. I > > have > > submitted a device tree related proposal for the Linux Plumbers 2015 > > conference > > to spur action and innovation in such tools, techniques, and debugging > > infrastructure. > > > > The current title of the track is "Device Tree Tools, Validation, and > > Troubleshooting". The proposal is located at > > > > > > http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting > > > > I am looking for several things at the moment: > > > >1) Suggestions of additional topics to be discussed. > > A few things on my list: > > - Supported and not supported overlay usecases > - Tools for overlays - I think overlays has created new challenges in > validation and a need for new tools. How to test an overlay applies? > Generating a dtb from dts + overlay dts. Generating an overlay from a > diff of old and new dts (overlay as a way to update old dtbs) > - Shrinking the binding review fire hose. How to improve binding > documentation structure and review. > - Standardizing Android dtb handling. Appended DTB for arm64? Not > liked by upstream, but already in use. - Clean up of existing hardware-specific bindings to conform to the generic bindings, working dts files in the kernel tree, and bring consistency to the documentation style/syntax. > >2) Emails or other messages expressing an interest in attending the > > device tree track. > > > >3) Commitments to attend the device tree track (the conference committee > > is looking at attendee interest and commitments as part of the process > > of accepting the device tree track). > > I plan to attend. I'm probably attending some of the Android mini conf > too, so I'll have to split my time. > > >4) Identifying additional people who should attend the device tree track. > > Arnd Bergmann > Matt Porter > Jon Loeliger > Gaurav Minocha I also plan to attend. I have an interest in most of the topics already mentioned as well as the topic I added above. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
On Tue, Apr 14, 2015 at 10:36:15AM -0500, Rob Herring wrote: On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank frank.row...@sonymobile.com wrote: In recent years there have been proposed tools to aid in the creation of valid device trees and in debugging device tree issues. An example of this is the various approaches proposed (with source code provided) to validate device tree source against valid bindings. As of today, device tree related tools, techniques, and debugging infrastructure have not progressed very far. I have submitted a device tree related proposal for the Linux Plumbers 2015 conference to spur action and innovation in such tools, techniques, and debugging infrastructure. The current title of the track is Device Tree Tools, Validation, and Troubleshooting. The proposal is located at http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting I am looking for several things at the moment: 1) Suggestions of additional topics to be discussed. A few things on my list: - Supported and not supported overlay usecases - Tools for overlays - I think overlays has created new challenges in validation and a need for new tools. How to test an overlay applies? Generating a dtb from dts + overlay dts. Generating an overlay from a diff of old and new dts (overlay as a way to update old dtbs) - Shrinking the binding review fire hose. How to improve binding documentation structure and review. - Standardizing Android dtb handling. Appended DTB for arm64? Not liked by upstream, but already in use. - Clean up of existing hardware-specific bindings to conform to the generic bindings, working dts files in the kernel tree, and bring consistency to the documentation style/syntax. 2) Emails or other messages expressing an interest in attending the device tree track. 3) Commitments to attend the device tree track (the conference committee is looking at attendee interest and commitments as part of the process of accepting the device tree track). I plan to attend. I'm probably attending some of the Android mini conf too, so I'll have to split my time. 4) Identifying additional people who should attend the device tree track. Arnd Bergmann Matt Porter Jon Loeliger Gaurav Minocha I also plan to attend. I have an interest in most of the topics already mentioned as well as the topic I added above. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Tue, Apr 07, 2015 at 07:03:30PM +0100, Srinivas Kandagatla wrote: > > > On 07/04/15 18:46, Mark Brown wrote: > >On Tue, Apr 07, 2015 at 06:35:49PM +0100, Srinivas Kandagatla wrote: > >>On 06/04/15 16:04, Matt Porter wrote: > >>>On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote: > > > >>>>>The generic binding could really use a "read-only" property here as this > >>>>>is a common hardware attribute for many nvmem devices. A serial EEPROM > > > >>Correct me If am wrong. > > > >>Regarding write protection/read-only, regmap already has provisions to > >>support this feature. regmap would bail out with errors if any attempt to > >>write to non-writable regions. It all depends on the data providers how they > >>setup the regmap and the bindings for those are specific individual data > >>providers I think. > > > >There is the ability to flag read/write permissions in regmap but I > >think there's some suggestion that this should be exposed to userspace > >so that it's easier for it to handle things rather than just writing > >then coping with any errors. > > Yes, That's possible if the data provider use the "read-only" generic > binding like MTD partitions which the eeprom framwork could use to set the > binary file mode appropriately. Right, that's what Rob suggested as to how it should be exposed to userspace. I think Mark is suggesting that it can also be done by returning appropriately fine-grained error codes from a writeable attribute. Just to clarify here, I brought this up because if we only allow the writes to fail, there's not necessarily not enough information available to know if they failed due to a real error (perhaps write cycles for the underlying nvmem device have been exhausted) or is it simply that the underlying device has been hardware write protected (such as as the write protect pin hardwired that way or it's an OTP device). The client, whether userspace or otherwise is going to need to know this information to make informed policy decisions. -Matt > "read-only" property seems to be more generic for all types of data > providers. > > I will give it a try and document this in the bindings too in next version. > > --srini > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Tue, Apr 07, 2015 at 07:03:30PM +0100, Srinivas Kandagatla wrote: On 07/04/15 18:46, Mark Brown wrote: On Tue, Apr 07, 2015 at 06:35:49PM +0100, Srinivas Kandagatla wrote: On 06/04/15 16:04, Matt Porter wrote: On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote: The generic binding could really use a read-only property here as this is a common hardware attribute for many nvmem devices. A serial EEPROM Correct me If am wrong. Regarding write protection/read-only, regmap already has provisions to support this feature. regmap would bail out with errors if any attempt to write to non-writable regions. It all depends on the data providers how they setup the regmap and the bindings for those are specific individual data providers I think. There is the ability to flag read/write permissions in regmap but I think there's some suggestion that this should be exposed to userspace so that it's easier for it to handle things rather than just writing then coping with any errors. Yes, That's possible if the data provider use the read-only generic binding like MTD partitions which the eeprom framwork could use to set the binary file mode appropriately. Right, that's what Rob suggested as to how it should be exposed to userspace. I think Mark is suggesting that it can also be done by returning appropriately fine-grained error codes from a writeable attribute. Just to clarify here, I brought this up because if we only allow the writes to fail, there's not necessarily not enough information available to know if they failed due to a real error (perhaps write cycles for the underlying nvmem device have been exhausted) or is it simply that the underlying device has been hardware write protected (such as as the write protect pin hardwired that way or it's an OTP device). The client, whether userspace or otherwise is going to need to know this information to make informed policy decisions. -Matt read-only property seems to be more generic for all types of data providers. I will give it a try and document this in the bindings too in next version. --srini -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote: > On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter wrote: > > On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote: > >> This patch adds bindings for simple eeprom framework which allows eeprom > >> consumers to talk to eeprom providers to get access to eeprom cell data. > >> > >> Signed-off-by: Maxime Ripard > >> [Maxime Ripard: intial version of eeprom framework] > >> Signed-off-by: Srinivas Kandagatla > >> --- > >> .../devicetree/bindings/eeprom/eeprom.txt | 58 > >> ++ > >> 1 file changed, 58 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt > >> > >> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt > >> b/Documentation/devicetree/bindings/eeprom/eeprom.txt > >> new file mode 100644 > >> index 000..fb71d46 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt > >> @@ -0,0 +1,58 @@ > >> += EEPROM Data Device Tree Bindings = > >> + > >> +This binding is intended to represent the location of hardware > >> +configuration data stored in EEPROMs. > >> + > >> +On a significant proportion of boards, the manufacturer has stored > >> +some data on an EEPROM-like device, for the OS to be able to retrieve > >> +these information and act upon it. Obviously, the OS has to know > >> +about where to retrieve these data from, and where they are stored on > >> +the storage device. > > > > Since this binding (and the kernel framework supporting it) describes > > non-volatile memory devices other than EEPROMs (e.g. EFuses) it should > > be named more generically like "nvmem". > > > >> + > >> +This document is here to document this. > >> + > >> += Data providers = > >> +Contains bindings specific to provider drivers and data cells as children > >> +to this node. > >> + > >> += Data cells = > >> +These are the child nodes of the provider which contain data cell > >> +information like offset and size in eeprom provider. > >> + > >> +Required properties: > >> +reg: specifies the offset in byte within that storage device, and the > >> length > >> + in bytes of the data we care about. > >> + There could be more then one offset-length pairs in this property. > >> + > >> +Optional properties: > >> +As required by specific data parsers/interpreters. > > > > The generic binding could really use a "read-only" property here as this > > is a common hardware attribute for many nvmem devices. A serial EEPROM > > commonly has a write protect pin which may be hard-wired such that the > > hardware description should reflect that. An EFuse is typically blown with > > the required information at manufacturing time (for an end product case) > > and would be marked with the "read-only" flag. > > > > Having this optional flag in the generic binding would allow the > > framework to hint to consumers about the inability to write to the > > provided region. > > This could get fairly complex if you wanted to describe grouping of WP > regions which could have different layout than the fields here. This > may be better left as a device property listing addr & size pairs. > However, there is the notion of s/w "read-only" which means the OS > should not allow write access. The MTD partition binding supports this > with the "read-only" property. Yes, if the backing device has the capability to hw write protect regions the exported fields overlap those then it does get ugly. The MTD partition property was the inspiration here so perhaps it's best to term this as a property indicating how the data region is used in an implementation. If it's left as a device property, then a binding with this property would need to be defined for the Efuse, etc. cases..or a simple-nvmem binding to handle the various OTP technologies. > > The framework sysfs attributes provide a userspace EEPROM consumer where > > it would be useful information to know that a data provider region is > > read only rather than having the exported writeable attribute simply > > fail a write cycle. This would allow the consumer to be aware that a > > failed write (if even attempted) is expected if the data provider > > advertised itself as read-only. > > You could distinguish with RW versus RO file attributes. Right, that would be preferred, based on the what the data provider advertises. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] dt-bindings: Document the hi6220 thermal sensor bindings
On Tue, Mar 31, 2015 at 02:59:21PM +0800, Xinwei Kong wrote:
> From: kongxinwei
>
> This adds documentation of device tree bindings for the
> thermal sensor controller of hi6220 SoC.
>
> Signed-off-by: Leo Yan
> Signed-off-by: kongxinwei
> ---
> .../bindings/thermal/hisilicon-thermal.txt | 45
> ++
> 1 file changed, 45 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> new file mode 100644
> index 000..ceb6e2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> @@ -0,0 +1,45 @@
> +* Hisilicon Thermal
> +
> +This driver is for hi6220 SoC which contain 4 thermal sensor.
> +
> + 1. sensor 0: local sensor;
> + 2. sensor 1: remote sensor for ACPU cluster 1;
> + 3. sensor 2: remote sensor for ACPU cluster 2;
> + 4. sensor 3: remote sensor for GPU.
> +
> +Every sensor use one child node to represent it, so thermal sensor include
> +parent node and four child node. The parent node describe common feature and
> +child node describe private feature for thermal sensor;
> +
> +** Required properties :
> +
> +- compatible: "hisilicon,tsensor".
> +- reg: physical base address of thermal sensor and length of memory mapped
> + region.
> +- interrupt: The interrupt number to the cpu. Defines the interrupt used
> + by SOCTHERM.
> +- clock-names: Input clock name, should be 'thermal_clk'.
> +- clocks: phandles for clock specified in "clock-names" property.
> +- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
> +
> +** Required properties for child nodes :
> +
> +- hisilicon,tsensor-id: the index of thermal sensor and use it to distinguish
> + thermal sensor. For example: <0> stands for local sensor; <1> stands for
> + acpu1 sensor;
Please show an example illustrating why this property is needed. The
example below doesn't show any per sensor properties aside from the
sensor id. Other bindings with a similar sub-sensor hardware design like
tegra-soctherm and rockchip-thermal don't have a need for a vendor
specific property like this. Their drivers simply iterate over an id
index during thermal sensor registration.
-Matt
> +
> +Example :
> +
> + tsensor: tsensor@0,f7030700 {
> + compatible = "hisilicon,tsensor";
> + reg = <0x0 0xf7030700 0x0 0x1000>;
> + interrupts = <0 7 0x4>;
> + clocks = <_sys HI6220_TSENSOR_CLK>;
> + clock-names = "thermal_clk";
> + #thermal-sensor-cells = <1>;
> +
> + local_sensor {
> + hisilicon,tsensor-id = <0>;
> + }
> + ...
> + }
> --
> 1.9.1
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for simple eeprom framework which allows eeprom
> consumers to talk to eeprom providers to get access to eeprom cell data.
>
> Signed-off-by: Maxime Ripard
> [Maxime Ripard: intial version of eeprom framework]
> Signed-off-by: Srinivas Kandagatla
> ---
> .../devicetree/bindings/eeprom/eeprom.txt | 58
> ++
> 1 file changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> new file mode 100644
> index 000..fb71d46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -0,0 +1,58 @@
> += EEPROM Data Device Tree Bindings =
> +
> +This binding is intended to represent the location of hardware
> +configuration data stored in EEPROMs.
> +
> +On a significant proportion of boards, the manufacturer has stored
> +some data on an EEPROM-like device, for the OS to be able to retrieve
> +these information and act upon it. Obviously, the OS has to know
> +about where to retrieve these data from, and where they are stored on
> +the storage device.
Since this binding (and the kernel framework supporting it) describes
non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
be named more generically like "nvmem".
> +
> +This document is here to document this.
> +
> += Data providers =
> +Contains bindings specific to provider drivers and data cells as children
> +to this node.
> +
> += Data cells =
> +These are the child nodes of the provider which contain data cell
> +information like offset and size in eeprom provider.
> +
> +Required properties:
> +reg: specifies the offset in byte within that storage device, and the length
> + in bytes of the data we care about.
> + There could be more then one offset-length pairs in this property.
> +
> +Optional properties:
> +As required by specific data parsers/interpreters.
The generic binding could really use a "read-only" property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM
commonly has a write protect pin which may be hard-wired such that the
hardware description should reflect that. An EFuse is typically blown with
the required information at manufacturing time (for an end product case)
and would be marked with the "read-only" flag.
Having this optional flag in the generic binding would allow the
framework to hint to consumers about the inability to write to the
provided region.
The framework sysfs attributes provide a userspace EEPROM consumer where
it would be useful information to know that a data provider region is
read only rather than having the exported writeable attribute simply
fail a write cycle. This would allow the consumer to be aware that a
failed write (if even attempted) is expected if the data provider
advertised itself as read-only.
-Matt
> +
> +For example:
> +
> + /* Provider */
> + qfprom: qfprom@0070 {
> + compatible = "qcom,qfprom";
> + reg = <0x0070 0x8000>;
> + ...
> +
> + /* Data cells */
> + tsens_calibration: calib@4404 {
> + reg = <0x4404 0x10>;
> + };
> +
> + serial_number: sn {
> + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
> +
> + };
> + ...
> + };
> +
> += Data consumers =
> +Are device nodes which consume eeprom data cells.
> +
> +For example:
> +
> + tsens {
> + ...
> + calibration = <_calibration>;
> + };
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
.../devicetree/bindings/eeprom/eeprom.txt | 58
++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
new file mode 100644
index 000..fb71d46
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -0,0 +1,58 @@
+= EEPROM Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in EEPROMs.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on an EEPROM-like device, for the OS to be able to retrieve
+these information and act upon it. Obviously, the OS has to know
+about where to retrieve these data from, and where they are stored on
+the storage device.
Since this binding (and the kernel framework supporting it) describes
non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
be named more generically like nvmem.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+to this node.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in eeprom provider.
+
+Required properties:
+reg: specifies the offset in byte within that storage device, and the length
+ in bytes of the data we care about.
+ There could be more then one offset-length pairs in this property.
+
+Optional properties:
+As required by specific data parsers/interpreters.
The generic binding could really use a read-only property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM
commonly has a write protect pin which may be hard-wired such that the
hardware description should reflect that. An EFuse is typically blown with
the required information at manufacturing time (for an end product case)
and would be marked with the read-only flag.
Having this optional flag in the generic binding would allow the
framework to hint to consumers about the inability to write to the
provided region.
The framework sysfs attributes provide a userspace EEPROM consumer where
it would be useful information to know that a data provider region is
read only rather than having the exported writeable attribute simply
fail a write cycle. This would allow the consumer to be aware that a
failed write (if even attempted) is expected if the data provider
advertised itself as read-only.
-Matt
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@0070 {
+ compatible = qcom,qfprom;
+ reg = 0x0070 0x8000;
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@4404 {
+ reg = 0x4404 0x10;
+ };
+
+ serial_number: sn {
+ reg = 0x104 0x4, 0x204 0x4, 0x30c 0x4;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+For example:
+
+ tsens {
+ ...
+ calibration = tsens_calibration;
+ };
--
1.9.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] dt-bindings: Document the hi6220 thermal sensor bindings
On Tue, Mar 31, 2015 at 02:59:21PM +0800, Xinwei Kong wrote:
From: kongxinwei kong.kongxin...@hisilicon.com
This adds documentation of device tree bindings for the
thermal sensor controller of hi6220 SoC.
Signed-off-by: Leo Yan leo@linaro.org
Signed-off-by: kongxinwei kong.kongxin...@hisilicon.com
---
.../bindings/thermal/hisilicon-thermal.txt | 45
++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
new file mode 100644
index 000..ceb6e2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
@@ -0,0 +1,45 @@
+* Hisilicon Thermal
+
+This driver is for hi6220 SoC which contain 4 thermal sensor.
+
+ 1. sensor 0: local sensor;
+ 2. sensor 1: remote sensor for ACPU cluster 1;
+ 3. sensor 2: remote sensor for ACPU cluster 2;
+ 4. sensor 3: remote sensor for GPU.
+
+Every sensor use one child node to represent it, so thermal sensor include
+parent node and four child node. The parent node describe common feature and
+child node describe private feature for thermal sensor;
+
+** Required properties :
+
+- compatible: hisilicon,tsensor.
+- reg: physical base address of thermal sensor and length of memory mapped
+ region.
+- interrupt: The interrupt number to the cpu. Defines the interrupt used
+ by SOCTHERM.
+- clock-names: Input clock name, should be 'thermal_clk'.
+- clocks: phandles for clock specified in clock-names property.
+- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
+
+** Required properties for child nodes :
+
+- hisilicon,tsensor-id: the index of thermal sensor and use it to distinguish
+ thermal sensor. For example: 0 stands for local sensor; 1 stands for
+ acpu1 sensor;
Please show an example illustrating why this property is needed. The
example below doesn't show any per sensor properties aside from the
sensor id. Other bindings with a similar sub-sensor hardware design like
tegra-soctherm and rockchip-thermal don't have a need for a vendor
specific property like this. Their drivers simply iterate over an id
index during thermal sensor registration.
-Matt
+
+Example :
+
+ tsensor: tsensor@0,f7030700 {
+ compatible = hisilicon,tsensor;
+ reg = 0x0 0xf7030700 0x0 0x1000;
+ interrupts = 0 7 0x4;
+ clocks = clock_sys HI6220_TSENSOR_CLK;
+ clock-names = thermal_clk;
+ #thermal-sensor-cells = 1;
+
+ local_sensor {
+ hisilicon,tsensor-id = 0;
+ }
+ ...
+ }
--
1.9.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote: On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter mpor...@konsulko.com wrote: On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote: This patch adds bindings for simple eeprom framework which allows eeprom consumers to talk to eeprom providers to get access to eeprom cell data. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com [Maxime Ripard: intial version of eeprom framework] Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- .../devicetree/bindings/eeprom/eeprom.txt | 58 ++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt new file mode 100644 index 000..fb71d46 --- /dev/null +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt @@ -0,0 +1,58 @@ += EEPROM Data Device Tree Bindings = + +This binding is intended to represent the location of hardware +configuration data stored in EEPROMs. + +On a significant proportion of boards, the manufacturer has stored +some data on an EEPROM-like device, for the OS to be able to retrieve +these information and act upon it. Obviously, the OS has to know +about where to retrieve these data from, and where they are stored on +the storage device. Since this binding (and the kernel framework supporting it) describes non-volatile memory devices other than EEPROMs (e.g. EFuses) it should be named more generically like nvmem. + +This document is here to document this. + += Data providers = +Contains bindings specific to provider drivers and data cells as children +to this node. + += Data cells = +These are the child nodes of the provider which contain data cell +information like offset and size in eeprom provider. + +Required properties: +reg: specifies the offset in byte within that storage device, and the length + in bytes of the data we care about. + There could be more then one offset-length pairs in this property. + +Optional properties: +As required by specific data parsers/interpreters. The generic binding could really use a read-only property here as this is a common hardware attribute for many nvmem devices. A serial EEPROM commonly has a write protect pin which may be hard-wired such that the hardware description should reflect that. An EFuse is typically blown with the required information at manufacturing time (for an end product case) and would be marked with the read-only flag. Having this optional flag in the generic binding would allow the framework to hint to consumers about the inability to write to the provided region. This could get fairly complex if you wanted to describe grouping of WP regions which could have different layout than the fields here. This may be better left as a device property listing addr size pairs. However, there is the notion of s/w read-only which means the OS should not allow write access. The MTD partition binding supports this with the read-only property. Yes, if the backing device has the capability to hw write protect regions the exported fields overlap those then it does get ugly. The MTD partition property was the inspiration here so perhaps it's best to term this as a property indicating how the data region is used in an implementation. If it's left as a device property, then a binding with this property would need to be defined for the Efuse, etc. cases..or a simple-nvmem binding to handle the various OTP technologies. The framework sysfs attributes provide a userspace EEPROM consumer where it would be useful information to know that a data provider region is read only rather than having the exported writeable attribute simply fail a write cycle. This would allow the consumer to be aware that a failed write (if even attempted) is expected if the data provider advertised itself as read-only. You could distinguish with RW versus RO file attributes. Right, that would be preferred, based on the what the data provider advertises. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pwm: imx-pwm: add explicit compatible strings and required clock properties
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be "fsl,-pwm". Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter
---
Changes since v1:
- compatible strings include the actual soc and one of the two specific
compatible parts.
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..e00c2e9 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,17 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be "fsl,-pwm"
+- compatible : should be "fsl,-pwm" and one of the following
+ compatible strings:
+ - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
+ - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both "ipg" and "per"
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +20,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = <2>;
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
+ clocks = < IMX5_CLK_PWM1_IPG_GATE>,
+< IMX5_CLK_PWM1_HF_GATE>;
+ clock-names = "ipg", "per";
interrupts = <61>;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] pwm: imx-pwm: add explicit compatible strings and required clock properties
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be fsl,soc-pwm. Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Changes since v1:
- compatible strings include the actual soc and one of the two specific
compatible parts.
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..e00c2e9 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,17 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be fsl,soc-pwm
+- compatible : should be fsl,soc-pwm and one of the following
+ compatible strings:
+ - fsl,imx1-pwm for PWM compatible with the one integrated on i.MX1
+ - fsl,imx27-pwm for PWM compatible with the one integrated on i.MX27
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both ipg and per
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +20,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = 2;
compatible = fsl,imx53-pwm, fsl,imx27-pwm;
reg = 0x53fb4000 0x4000;
+ clocks = clks IMX5_CLK_PWM1_IPG_GATE,
+clks IMX5_CLK_PWM1_HF_GATE;
+ clock-names = ipg, per;
interrupts = 61;
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
On Fri, Mar 06, 2015 at 09:16:44AM -0600, Rob Herring wrote:
> On Fri, Mar 6, 2015 at 9:09 AM, Matt Porter wrote:
> > The imx-pwm binding contains language indicating compatible
> > strings to be used that is not valid for all supported parts
> > e.g. Should be "fsl,-pwm". Fix this by enumerating the
> > valid compatible strings that represent the two versions of
> > this peripheral in use.
> >
> > The binding is also missing the clocks/clock-names properties
> > so document these,the two required ipg and per clocks, and add
> > add these properties to the example.
> >
> > Signed-off-by: Matt Porter
> > ---
> > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > index b50d7a6d..30d2b82 100644
> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > @@ -1,10 +1,16 @@
> > Freescale i.MX PWM controller
> >
> > Required properties:
> > -- compatible: should be "fsl,-pwm"
> > +- compatible :
> > + - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> > + - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
>
> This should be one of these and a more specific value as the example
> below shows.
Ok, yes, I wasn't sure if that was expected to be explicit in the bindings
or not as others don't seem to represent that properly. What about this?
- compatible: should be "fsl,-pwm" and one of the following
compatible strings:
"fsl,imx1-pwm" for an iMX1 compatible PWM
"fsl,imx27-pwm" for an iMX27 compatible PWM
> > - reg: physical base address and length of the controller's registers
> > - #pwm-cells: should be 2. See pwm.txt in this directory for a description
> > of
> >the cells format.
> > +- clocks : Clock specifiers for both ipg and per clocks.
> > +- clock-names : Clock names should include both "ipg" and "per"
> > +See the clock consumer binding,
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt
> > - interrupts: The interrupt for the pwm controller
> >
> > Example:
> > @@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
> > #pwm-cells = <2>;
> > compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> > reg = <0x53fb4000 0x4000>;
> > + clocks = < IMX5_CLK_PWM1_IPG_GATE>,
> > +< IMX5_CLK_PWM1_HF_GATE>;
> > + clock-names = "ipg", "per";
> > interrupts = <61>;
> > };
> > --
> > 1.8.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] serial: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be "uart", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = "ti,omap3-uart";
+reg = <0x49042000 0x400>;
+interrupts = <80>;
+dmas = < 81 82>;
+dma-names = "tx", "rx";
+ti,hwmods = "uart4";
+clock-frequency = <4800>;
+};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be "fsl,-pwm". Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..30d2b82 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,16 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be "fsl,-pwm"
+- compatible :
+ - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
+ - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both "ipg" and "per"
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = <2>;
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
+ clocks = < IMX5_CLK_PWM1_IPG_GATE>,
+< IMX5_CLK_PWM1_HF_GATE>;
+ clock-names = "ipg", "per";
interrupts = <61>;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] serial: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be ti,omap2-uart for OMAP2 controllers
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be uartn, n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : rx for receive channel, tx for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = ti,omap3-uart;
+reg = 0x49042000 0x400;
+interrupts = 80;
+dmas = sdma 81 sdma 82;
+dma-names = tx, rx;
+ti,hwmods = uart4;
+clock-frequency = 4800;
+};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be fsl,soc-pwm. Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..30d2b82 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,16 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be fsl,soc-pwm
+- compatible :
+ - fsl,imx1-pwm for PWM compatible with the one integrated on i.MX1
+ - fsl,imx27-pwm for PWM compatible with the one integrated on i.MX27
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both ipg and per
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = 2;
compatible = fsl,imx53-pwm, fsl,imx27-pwm;
reg = 0x53fb4000 0x4000;
+ clocks = clks IMX5_CLK_PWM1_IPG_GATE,
+clks IMX5_CLK_PWM1_HF_GATE;
+ clock-names = ipg, per;
interrupts = 61;
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
On Fri, Mar 06, 2015 at 09:16:44AM -0600, Rob Herring wrote:
On Fri, Mar 6, 2015 at 9:09 AM, Matt Porter mpor...@konsulko.com wrote:
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be fsl,soc-pwm. Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..30d2b82 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,16 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be fsl,soc-pwm
+- compatible :
+ - fsl,imx1-pwm for PWM compatible with the one integrated on i.MX1
+ - fsl,imx27-pwm for PWM compatible with the one integrated on i.MX27
This should be one of these and a more specific value as the example
below shows.
Ok, yes, I wasn't sure if that was expected to be explicit in the bindings
or not as others don't seem to represent that properly. What about this?
- compatible: should be fsl,soc-pwm and one of the following
compatible strings:
fsl,imx1-pwm for an iMX1 compatible PWM
fsl,imx27-pwm for an iMX27 compatible PWM
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description
of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both ipg and per
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = 2;
compatible = fsl,imx53-pwm, fsl,imx27-pwm;
reg = 0x53fb4000 0x4000;
+ clocks = clks IMX5_CLK_PWM1_IPG_GATE,
+clks IMX5_CLK_PWM1_HF_GATE;
+ clock-names = ipg, per;
interrupts = 61;
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dt: submitting-patches: clarify that DT maintainers are to be cced on bindings
The exact steps provided for submitting binding patches can be read as requiring the bindings to be sent only to the devicet...@vger.kernel.org list. Since the DT maintainers would like to be Cced on any binding submissions, make this requirement explicit in step 2. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/submitting-patches.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index 56742bc..7d44eae 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -12,6 +12,9 @@ I. For patch submitters devicet...@vger.kernel.org + and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify + all of the DT maintainers. + 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
Hi Florian, That email address is dead now so can you pick this up for 4.0 fixes? Thanks, Matt On Tue, Feb 17, 2015 at 12:17:57PM -0500, Matt Porter wrote: > Removing myself as a co-maintainer. > > Signed-off-by: Matt Porter > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2ebb056..e21438b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2077,7 +2077,6 @@ F: drivers/net/ethernet/broadcom/bnx2x/ > > BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE > M: Christian Daudt > -M: Matt Porter > M: Florian Fainelli > L: bcm-kernel-feedback-l...@broadcom.com > T: git git://github.com/broadcom/mach-bcm > -- > 1.8.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dt: submitting-patches: clarify that DT maintainers are to be cced on bindings
The exact steps provided for submitting binding patches can be read as requiring the bindings to be sent only to the devicet...@vger.kernel.org list. Since the DT maintainers would like to be Cced on any binding submissions, make this requirement explicit in step 2. Signed-off-by: Matt Porter mpor...@konsulko.com --- Documentation/devicetree/bindings/submitting-patches.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index 56742bc..7d44eae 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -12,6 +12,9 @@ I. For patch submitters devicet...@vger.kernel.org + and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify + all of the DT maintainers. + 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
Hi Florian, That email address is dead now so can you pick this up for 4.0 fixes? Thanks, Matt On Tue, Feb 17, 2015 at 12:17:57PM -0500, Matt Porter wrote: Removing myself as a co-maintainer. Signed-off-by: Matt Porter mpor...@linaro.org --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2ebb056..e21438b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2077,7 +2077,6 @@ F: drivers/net/ethernet/broadcom/bnx2x/ BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE M: Christian Daudt b...@fixthebug.org -M: Matt Porter mpor...@linaro.org M: Florian Fainelli f.faine...@gmail.com L: bcm-kernel-feedback-l...@broadcom.com T: git git://github.com/broadcom/mach-bcm -- 1.8.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dt: spi: fsl-imx-cspi: add explicit compatible strings and required clock properties
The fsl-imx-cspi binding contains language indicating compatible strings to be used that is not valid for all supported parts e.g. Should be "fsl,-cspi" or "fsl,-ecspi". Fix this by enumerating the set of valid compatible strings. The binding is also missing the clocks/clock-names properties so document these and the two required ipg and per clocks. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt index aad527b..523341a 100644 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt @@ -2,11 +2,21 @@ (CSPI/eCSPI) for i.MX Required properties: -- compatible : Should be "fsl,-cspi" or "fsl,-ecspi" +- compatible : + - "fsl,imx1-cspi" for SPI compatible with the one integrated on i.MX1 + - "fsl,imx21-cspi" for SPI compatible with the one integrated on i.MX21 + - "fsl,imx27-cspi" for SPI compatible with the one integrated on i.MX27 + - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31 + - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 + - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51 - reg : Offset and length of the register set for the device - interrupts : Should contain CSPI/eCSPI interrupt - fsl,spi-num-chipselects : Contains the number of the chipselect - cs-gpios : Specifies the gpio pins to be used for chipselects. +- clocks : Clock specifiers for both ipg and per clocks. +- clock-names : Clock names should include both "ipg" and "per" +See the clock consumer binding, + Documentation/devicetree/bindings/clock/clock-bindings.txt - dmas: DMA specifiers for tx and rx dma. See the DMA client binding, Documentation/devicetree/bindings/dma/dma.txt - dma-names: DMA request names should include "tx" and "rx" if present. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dt: spi: fsl-imx-cspi: add explicit compatible strings and required clock properties
The fsl-imx-cspi binding contains language indicating compatible strings to be used that is not valid for all supported parts e.g. Should be fsl,soc-cspi or fsl,soc-ecspi. Fix this by enumerating the set of valid compatible strings. The binding is also missing the clocks/clock-names properties so document these and the two required ipg and per clocks. Signed-off-by: Matt Porter mpor...@konsulko.com --- Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt index aad527b..523341a 100644 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt @@ -2,11 +2,21 @@ (CSPI/eCSPI) for i.MX Required properties: -- compatible : Should be fsl,soc-cspi or fsl,soc-ecspi +- compatible : + - fsl,imx1-cspi for SPI compatible with the one integrated on i.MX1 + - fsl,imx21-cspi for SPI compatible with the one integrated on i.MX21 + - fsl,imx27-cspi for SPI compatible with the one integrated on i.MX27 + - fsl,imx31-cspi for SPI compatible with the one integrated on i.MX31 + - fsl,imx35-cspi for SPI compatible with the one integrated on i.MX35 + - fsl,imx51-ecspi for SPI compatible with the one integrated on i.MX51 - reg : Offset and length of the register set for the device - interrupts : Should contain CSPI/eCSPI interrupt - fsl,spi-num-chipselects : Contains the number of the chipselect - cs-gpios : Specifies the gpio pins to be used for chipselects. +- clocks : Clock specifiers for both ipg and per clocks. +- clock-names : Clock names should include both ipg and per +See the clock consumer binding, + Documentation/devicetree/bindings/clock/clock-bindings.txt - dmas: DMA specifiers for tx and rx dma. See the DMA client binding, Documentation/devicetree/bindings/dma/dma.txt - dma-names: DMA request names should include tx and rx if present. -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: imx: add required clocks property to binding
A clock specifier is required for i.MX I2C and is provided in all DTS implementations. Add this to the list of required properties in the binding. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/i2c/i2c-imx.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index 52d37fd..ce4311d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -7,6 +7,7 @@ Required properties: - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC - reg : Should contain I2C/HS-I2C registers location and length - interrupts : Should contain I2C/HS-I2C interrupt +- clocks : Should contain the I2C/HS-I2C clock specifier Optional properties: - clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
On Tue, Mar 03, 2015 at 12:43:36PM +0800, Peter Chen wrote: > On Tue, Mar 03, 2015 at 11:41:35AM +0800, Shawn Guo wrote: > > > > On Fri, Feb 27, 2015 at 09:06:00AM -0500, Matt Porter wrote: > > > The chipidea driver adds an extra line of spam to the log when a > > > host-only chipidea instance is left set to the default of a dual role > > > controller. > > > > > > [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget > > > > > > Set the dr_mode property to host on all the host-only nodes > > > to avoid this warning. > > It is not an warning, it is dev_info. True enough, it's info level but is essentially warning that, in the case of instances that are restricted to host only (at the SoC level), that the DT hardware description is incorrect. Yes, it's benign, but if the dtsi is corrected for those parts we don't have to see that message. > In fact, imx28, imx6sl and imx6sx's second controller is dual-role > controller, we only set dr_mode at board's dts according to design > unless the controller's capability register is incorrect. The patch doesn't set dr_mode to host on the second controller for the imx6sl or imx6sx, only on the third host-only controller. If imx28's second controller is really dual-role capable then the reference manual is incorrect and I can drop that hunk in v2. I only have imx6q and imx6d parts in hand to verify so for the rest I went by the RM claim of which controllers were host-only. > So, sorry, I don't think this change is necessary. I can correct the set of instances that should have dr_mode set to host in v2 of this. We clearly have some that should have this set in their SoC .dtsi to have the hardware description correct. Will that work for you or do you want the SoC-specific cases of this property to be only reflected in the board level dts? -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
On Tue, Mar 03, 2015 at 12:43:36PM +0800, Peter Chen wrote: On Tue, Mar 03, 2015 at 11:41:35AM +0800, Shawn Guo wrote: On Fri, Feb 27, 2015 at 09:06:00AM -0500, Matt Porter wrote: The chipidea driver adds an extra line of spam to the log when a host-only chipidea instance is left set to the default of a dual role controller. [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget Set the dr_mode property to host on all the host-only nodes to avoid this warning. It is not an warning, it is dev_info. True enough, it's info level but is essentially warning that, in the case of instances that are restricted to host only (at the SoC level), that the DT hardware description is incorrect. Yes, it's benign, but if the dtsi is corrected for those parts we don't have to see that message. In fact, imx28, imx6sl and imx6sx's second controller is dual-role controller, we only set dr_mode at board's dts according to design unless the controller's capability register is incorrect. The patch doesn't set dr_mode to host on the second controller for the imx6sl or imx6sx, only on the third host-only controller. If imx28's second controller is really dual-role capable then the reference manual is incorrect and I can drop that hunk in v2. I only have imx6q and imx6d parts in hand to verify so for the rest I went by the RM claim of which controllers were host-only. So, sorry, I don't think this change is necessary. I can correct the set of instances that should have dr_mode set to host in v2 of this. We clearly have some that should have this set in their SoC .dtsi to have the hardware description correct. Will that work for you or do you want the SoC-specific cases of this property to be only reflected in the board level dts? -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: imx: add required clocks property to binding
A clock specifier is required for i.MX I2C and is provided in all DTS implementations. Add this to the list of required properties in the binding. Signed-off-by: Matt Porter mpor...@konsulko.com --- Documentation/devicetree/bindings/i2c/i2c-imx.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index 52d37fd..ce4311d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -7,6 +7,7 @@ Required properties: - fsl,vf610-i2c for I2C compatible with the one integrated on Vybrid vf610 SoC - reg : Should contain I2C/HS-I2C registers location and length - interrupts : Should contain I2C/HS-I2C interrupt +- clocks : Should contain the I2C/HS-I2C clock specifier Optional properties: - clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
On Mon, Mar 02, 2015 at 08:43:26PM +, Russell King wrote: > On Mon, Mar 02, 2015 at 03:25:40PM -0500, Matt Porter wrote: > > On Mon, Mar 02, 2015 at 07:49:08PM +, Russell King wrote: > > > It's a bit like the MMC stuff, I'm still carrying Olof's solution for > > > the SDIO wifi/bt power and reset control stuff, and I'm not at present > > > intending to do anything with it other than continue forward-porting it. > > > I'm not interested in wasting free time trying to re-work that to suit > > > some other solution, especially as people couldn't settle on a solution > > > when I /did/ have an interest in it (not that I have much interest in > > > wifi or BT - I tend to prefer old fashioned wired connections. It also > > > doesn't help that the Broadcom driver seemed to be very flakey with > > > brcm4329 hardware for quite some time.) > > > > > > Anyway, you can find all my kernel patches in a suitably trimmed version > > > of the above URL, and on http://ftp.arm.linux.org.uk/cgit/ is a huge pile > > > of effort I put into an accelerated X server with etnaviv and /my/ kernel > > > version of etnaviv drm, complete with Xv support. > > > > Excellent, so I feel like you ultimately giving me mixed messages here. > > Yes, I am - partly because I don't know what to do with many of the > patches I seem to be endlessly carrying (which depresses me). I look > back to the days when I could be sure of completely emptying my tree > at each merge window, something which /never/ happens anymore. > > > You said you need to take care of this licensing issue and I think you > > implied you'd take care of the audio and rtc stuff as you have that > > patch in your backlog. > > As you may have seen, I've mailed out the licensing patch, and I've > also mailed out two patches - one for PWM stuff and the second one > being the RTC change broken out from my sgtl5000 hacks patch. > > I've also cut a v4.0-rc1 patch set, in the usual diff.bz2, tar.bz2, > and separate patch forms which include those three patches. Ok, caught up on those now, thanks. > > However, sounds like you've given up on pushing > > the bigger things upstream given the problem with getting agreement > > on those pieces. Are you just going to be submitting the > > less controversial portions like the audio and dts updates? My goal for > > HB initially is just to have all the low-hanging fruit (like rtc and audio) > > working on mainline...besides the stuff that's already there. > > RTC is the easiest bit of the problem, as you've discovered it's just > a matter of uncommenting the bit in DT. (It's even better if you have > a battery to plug into the little connector!) > > Audio needs more than just DT changes, and there's recently been some > SGTL5000 patches submitted which change the way power is controlled > in the SGTL5000. I don't yet know whether those patches solve the > problems I was seeing with the kernel powering down the SGTL5000's > internal regulator, thereby making the device totally inaccessible > until the next power cycle or not. Ok, I'll take a look at those here. > Whether I'll get a chance to look at that this week or not, I don't > know... (see my privately shared G+ status from yesterday, which > people in my G+ circles should be able to see.) Aha, ok, I only saw your last public mention of the 4.0-rc1 breakage on the ethernet clock. Now I know why. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
On Mon, Mar 02, 2015 at 07:49:08PM +, Russell King wrote: > On Mon, Mar 02, 2015 at 02:21:16PM -0500, Matt Porter wrote: > > [added Rabeeh] > > > > On Mon, Mar 02, 2015 at 07:06:16PM +, Russell King wrote: > > > On Mon, Mar 02, 2015 at 07:02:04PM +, Russell King - ARM Linux wrote: > > > > On Mon, Mar 02, 2015 at 01:50:06PM -0500, Matt Porter wrote: > > > > > The PCF8523 RTC is populated on the i2eX boards so > > > > > enable the i2c1 controller and enable the device on > > > > > that bus. > > > > > > > > Hmm, I wonder where my update patches went... oh, they're still sitting > > > > in my excessive backlog of patches in my tree as part of my "sgtl5000 > > > > hacks" patch... > > > > > > Also note that before we accept patches to the SolidRun stuff, we should > > > first re-license the file as GPLv2/X11. > > > > Hi Russell, > > > > Given that there's no license information at all on any of these three > > dts files I think that's a good idea. I just realized I didn't copy > > Rabeeh on this and he's apparently the original submitter based on > > your work. Ideally Rabeeh should send a license update but I could do > > so if you'd like and gather some acks. > > It's more up to me, as I ended up being the initial author of the > mainline files - and if you look at: > > http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.16-rc2-20140624/0041-sgtl5000-hacks.patch > > you'll see the patch I refer to above, which is my own work, and it's > hardly changed to the 3.18 patch: > > http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.18-20141216/0113-sgtl5000-hacks.patch Ok > > OTOH, did you already have a license update somewhere in your backlog > > of patches? > > Well, I do now. :) Ok :) > I had dropped the ball on a load of kernel stuff as it seemed to be going > nowhere, no one seemed interested in it, and my massive backlog of patches > (especially things like the ethernet driver) just became far too difficult > both to merge into mainline and to keep forward-porting. Understood, I recall that thread but didn't have the hardware back then. ;) > In any case, anyone who is serious about using the SolidRun hardware runs > Jon Nettleton's fully featured kernel (which is the basis for SR's kernel) > - sadly something which mainline likely is never going to be. Right, I also make use of that kernel, of course. It's just too old to make me completely happy. > It's a bit like the MMC stuff, I'm still carrying Olof's solution for > the SDIO wifi/bt power and reset control stuff, and I'm not at present > intending to do anything with it other than continue forward-porting it. > I'm not interested in wasting free time trying to re-work that to suit > some other solution, especially as people couldn't settle on a solution > when I /did/ have an interest in it (not that I have much interest in > wifi or BT - I tend to prefer old fashioned wired connections. It also > doesn't help that the Broadcom driver seemed to be very flakey with > brcm4329 hardware for quite some time.) > > Anyway, you can find all my kernel patches in a suitably trimmed version > of the above URL, and on http://ftp.arm.linux.org.uk/cgit/ is a huge pile > of effort I put into an accelerated X server with etnaviv and /my/ kernel > version of etnaviv drm, complete with Xv support. Excellent, so I feel like you ultimately giving me mixed messages here. You said you need to take care of this licensing issue and I think you implied you'd take care of the audio and rtc stuff as you have that patch in your backlog. However, sounds like you've given up on pushing the bigger things upstream given the problem with getting agreement on those pieces. Are you just going to be submitting the less controversial portions like the audio and dts updates? My goal for HB initially is just to have all the low-hanging fruit (like rtc and audio) working on mainline...besides the stuff that's already there. Hrm, I also don't care about WiFi/BT on this board, I also prefer wired, but on a custom board I'll have to support a different WiFi/BT vendor so I'll take a look at that reset solution you are carrying. Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
[added Rabeeh] On Mon, Mar 02, 2015 at 07:06:16PM +, Russell King wrote: > On Mon, Mar 02, 2015 at 07:02:04PM +, Russell King - ARM Linux wrote: > > On Mon, Mar 02, 2015 at 01:50:06PM -0500, Matt Porter wrote: > > > The PCF8523 RTC is populated on the i2eX boards so > > > enable the i2c1 controller and enable the device on > > > that bus. > > > > Hmm, I wonder where my update patches went... oh, they're still sitting > > in my excessive backlog of patches in my tree as part of my "sgtl5000 > > hacks" patch... > > Also note that before we accept patches to the SolidRun stuff, we should > first re-license the file as GPLv2/X11. Hi Russell, Given that there's no license information at all on any of these three dts files I think that's a good idea. I just realized I didn't copy Rabeeh on this and he's apparently the original submitter based on your work. Ideally Rabeeh should send a license update but I could do so if you'd like and gather some acks. OTOH, did you already have a license update somewhere in your backlog of patches? -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
The PCF8523 RTC is populated on the i2eX boards so
enable the i2c1 controller and enable the device on
that bus.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 62841e8..38ebba9 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -73,18 +73,15 @@
};
{
+ clock-frequency = <40>;
pinctrl-names = "default";
pinctrl-0 = <_hummingboard_i2c1>;
-
- /*
-* Not fitted on Carrier-1 board... yet
status = "okay";
rtc: pcf8523@68 {
compatible = "nxp,pcf8523";
reg = <0x68>;
};
-*/
};
{
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
On Mon, Mar 02, 2015 at 08:43:26PM +, Russell King wrote: On Mon, Mar 02, 2015 at 03:25:40PM -0500, Matt Porter wrote: On Mon, Mar 02, 2015 at 07:49:08PM +, Russell King wrote: It's a bit like the MMC stuff, I'm still carrying Olof's solution for the SDIO wifi/bt power and reset control stuff, and I'm not at present intending to do anything with it other than continue forward-porting it. I'm not interested in wasting free time trying to re-work that to suit some other solution, especially as people couldn't settle on a solution when I /did/ have an interest in it (not that I have much interest in wifi or BT - I tend to prefer old fashioned wired connections. It also doesn't help that the Broadcom driver seemed to be very flakey with brcm4329 hardware for quite some time.) Anyway, you can find all my kernel patches in a suitably trimmed version of the above URL, and on http://ftp.arm.linux.org.uk/cgit/ is a huge pile of effort I put into an accelerated X server with etnaviv and /my/ kernel version of etnaviv drm, complete with Xv support. Excellent, so I feel like you ultimately giving me mixed messages here. Yes, I am - partly because I don't know what to do with many of the patches I seem to be endlessly carrying (which depresses me). I look back to the days when I could be sure of completely emptying my tree at each merge window, something which /never/ happens anymore. You said you need to take care of this licensing issue and I think you implied you'd take care of the audio and rtc stuff as you have that patch in your backlog. As you may have seen, I've mailed out the licensing patch, and I've also mailed out two patches - one for PWM stuff and the second one being the RTC change broken out from my sgtl5000 hacks patch. I've also cut a v4.0-rc1 patch set, in the usual diff.bz2, tar.bz2, and separate patch forms which include those three patches. Ok, caught up on those now, thanks. However, sounds like you've given up on pushing the bigger things upstream given the problem with getting agreement on those pieces. Are you just going to be submitting the less controversial portions like the audio and dts updates? My goal for HB initially is just to have all the low-hanging fruit (like rtc and audio) working on mainline...besides the stuff that's already there. RTC is the easiest bit of the problem, as you've discovered it's just a matter of uncommenting the bit in DT. (It's even better if you have a battery to plug into the little connector!) Audio needs more than just DT changes, and there's recently been some SGTL5000 patches submitted which change the way power is controlled in the SGTL5000. I don't yet know whether those patches solve the problems I was seeing with the kernel powering down the SGTL5000's internal regulator, thereby making the device totally inaccessible until the next power cycle or not. Ok, I'll take a look at those here. Whether I'll get a chance to look at that this week or not, I don't know... (see my privately shared G+ status from yesterday, which people in my G+ circles should be able to see.) Aha, ok, I only saw your last public mention of the 4.0-rc1 breakage on the ethernet clock. Now I know why. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
The PCF8523 RTC is populated on the i2eX boards so
enable the i2c1 controller and enable the device on
that bus.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 62841e8..38ebba9 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -73,18 +73,15 @@
};
i2c1 {
+ clock-frequency = 40;
pinctrl-names = default;
pinctrl-0 = pinctrl_hummingboard_i2c1;
-
- /*
-* Not fitted on Carrier-1 board... yet
status = okay;
rtc: pcf8523@68 {
compatible = nxp,pcf8523;
reg = 0x68;
};
-*/
};
i2c2 {
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
[added Rabeeh] On Mon, Mar 02, 2015 at 07:06:16PM +, Russell King wrote: On Mon, Mar 02, 2015 at 07:02:04PM +, Russell King - ARM Linux wrote: On Mon, Mar 02, 2015 at 01:50:06PM -0500, Matt Porter wrote: The PCF8523 RTC is populated on the i2eX boards so enable the i2c1 controller and enable the device on that bus. Hmm, I wonder where my update patches went... oh, they're still sitting in my excessive backlog of patches in my tree as part of my sgtl5000 hacks patch... Also note that before we accept patches to the SolidRun stuff, we should first re-license the file as GPLv2/X11. Hi Russell, Given that there's no license information at all on any of these three dts files I think that's a good idea. I just realized I didn't copy Rabeeh on this and he's apparently the original submitter based on your work. Ideally Rabeeh should send a license update but I could do so if you'd like and gather some acks. OTOH, did you already have a license update somewhere in your backlog of patches? -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
On Mon, Mar 02, 2015 at 07:49:08PM +, Russell King wrote: On Mon, Mar 02, 2015 at 02:21:16PM -0500, Matt Porter wrote: [added Rabeeh] On Mon, Mar 02, 2015 at 07:06:16PM +, Russell King wrote: On Mon, Mar 02, 2015 at 07:02:04PM +, Russell King - ARM Linux wrote: On Mon, Mar 02, 2015 at 01:50:06PM -0500, Matt Porter wrote: The PCF8523 RTC is populated on the i2eX boards so enable the i2c1 controller and enable the device on that bus. Hmm, I wonder where my update patches went... oh, they're still sitting in my excessive backlog of patches in my tree as part of my sgtl5000 hacks patch... Also note that before we accept patches to the SolidRun stuff, we should first re-license the file as GPLv2/X11. Hi Russell, Given that there's no license information at all on any of these three dts files I think that's a good idea. I just realized I didn't copy Rabeeh on this and he's apparently the original submitter based on your work. Ideally Rabeeh should send a license update but I could do so if you'd like and gather some acks. It's more up to me, as I ended up being the initial author of the mainline files - and if you look at: http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.16-rc2-20140624/0041-sgtl5000-hacks.patch you'll see the patch I refer to above, which is my own work, and it's hardly changed to the 3.18 patch: http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.18-20141216/0113-sgtl5000-hacks.patch Ok OTOH, did you already have a license update somewhere in your backlog of patches? Well, I do now. :) Ok :) I had dropped the ball on a load of kernel stuff as it seemed to be going nowhere, no one seemed interested in it, and my massive backlog of patches (especially things like the ethernet driver) just became far too difficult both to merge into mainline and to keep forward-porting. Understood, I recall that thread but didn't have the hardware back then. ;) In any case, anyone who is serious about using the SolidRun hardware runs Jon Nettleton's fully featured kernel (which is the basis for SR's kernel) - sadly something which mainline likely is never going to be. Right, I also make use of that kernel, of course. It's just too old to make me completely happy. It's a bit like the MMC stuff, I'm still carrying Olof's solution for the SDIO wifi/bt power and reset control stuff, and I'm not at present intending to do anything with it other than continue forward-porting it. I'm not interested in wasting free time trying to re-work that to suit some other solution, especially as people couldn't settle on a solution when I /did/ have an interest in it (not that I have much interest in wifi or BT - I tend to prefer old fashioned wired connections. It also doesn't help that the Broadcom driver seemed to be very flakey with brcm4329 hardware for quite some time.) Anyway, you can find all my kernel patches in a suitably trimmed version of the above URL, and on http://ftp.arm.linux.org.uk/cgit/ is a huge pile of effort I put into an accelerated X server with etnaviv and /my/ kernel version of etnaviv drm, complete with Xv support. Excellent, so I feel like you ultimately giving me mixed messages here. You said you need to take care of this licensing issue and I think you implied you'd take care of the audio and rtc stuff as you have that patch in your backlog. However, sounds like you've given up on pushing the bigger things upstream given the problem with getting agreement on those pieces. Are you just going to be submitting the less controversial portions like the audio and dts updates? My goal for HB initially is just to have all the low-hanging fruit (like rtc and audio) working on mainline...besides the stuff that's already there. Hrm, I also don't care about WiFi/BT on this board, I also prefer wired, but on a custom board I'll have to support a different WiFi/BT vendor so I'll take a look at that reset solution you are carrying. Thanks, Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
The chipidea driver adds an extra line of spam to the log when a host-only chipidea instance is left set to the default of a dual role controller. [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget Set the dr_mode property to host on all the host-only nodes to avoid this warning. Signed-off-by: Matt Porter --- arch/arm/boot/dts/imx27.dtsi | 2 ++ arch/arm/boot/dts/imx28.dtsi | 1 + arch/arm/boot/dts/imx35.dtsi | 1 + arch/arm/boot/dts/imx50.dtsi | 3 +++ arch/arm/boot/dts/imx51.dtsi | 3 +++ arch/arm/boot/dts/imx53.dtsi | 3 +++ arch/arm/boot/dts/imx6qdl.dtsi | 3 +++ arch/arm/boot/dts/imx6sl.dtsi | 1 + arch/arm/boot/dts/imx6sx.dtsi | 1 + 9 files changed, 18 insertions(+) diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi index 4b063b6..6951b66 100644 --- a/arch/arm/boot/dts/imx27.dtsi +++ b/arch/arm/boot/dts/imx27.dtsi @@ -488,6 +488,7 @@ interrupts = <54>; clocks = < IMX27_CLK_USB_IPG_GATE>; fsl,usbmisc = < 1>; + dr_mode = "host"; status = "disabled"; }; @@ -497,6 +498,7 @@ interrupts = <55>; clocks = < IMX27_CLK_USB_IPG_GATE>; fsl,usbmisc = < 2>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi index 47f68ac..02330f4 100644 --- a/arch/arm/boot/dts/imx28.dtsi +++ b/arch/arm/boot/dts/imx28.dtsi @@ -1197,6 +1197,7 @@ interrupts = <92>; clocks = < 61>; fsl,usbphy = <>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi index 6932928..b6478e9 100644 --- a/arch/arm/boot/dts/imx35.dtsi +++ b/arch/arm/boot/dts/imx35.dtsi @@ -318,6 +318,7 @@ clocks = < 73>; fsl,usbmisc = < 1>; fsl,usbphy = <>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi index 620b0f0..e245713 100644 --- a/arch/arm/boot/dts/imx50.dtsi +++ b/arch/arm/boot/dts/imx50.dtsi @@ -197,6 +197,7 @@ reg = <0x53f80200 0x0200>; interrupts = <14>; clocks = < IMX5_CLK_USB_PHY2_GATE>; + dr_mode = "host"; status = "disabled"; }; @@ -205,6 +206,7 @@ reg = <0x53f80400 0x0200>; interrupts = <16>; clocks = < IMX5_CLK_USBOH3_GATE>; + dr_mode = "host"; status = "disabled"; }; @@ -213,6 +215,7 @@ reg = <0x53f80600 0x0200>; interrupts = <17>; clocks = < IMX5_CLK_USBOH3_GATE>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi index c0116cf..f46fe9b 100644 --- a/arch/arm/boot/dts/imx51.dtsi +++ b/arch/arm/boot/dts/imx51.dtsi @@ -265,6 +265,7 @@ interrupts = <14>; clocks = < IMX5_CLK_USBOH3_GATE>; fsl,usbmisc = < 1>; + dr_mode = "host"; status = "disabled"; }; @@ -274,6 +275,7 @@ interrupts = <16>; clocks = < IMX5_CLK_USBOH3_GATE>; fsl,usbmisc = < 2>; + dr_mode = "host"; status = "disabled"; }; @@ -283,6 +285,7 @@ interrupts = <17>; clocks = < IMX5_CLK_USBOH3_GATE>; fsl,usbmisc = < 3>; +
[PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
The chipidea driver adds an extra line of spam to the log when a host-only chipidea instance is left set to the default of a dual role controller. [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget Set the dr_mode property to host on all the host-only nodes to avoid this warning. Signed-off-by: Matt Porter mpor...@konsulko.com --- arch/arm/boot/dts/imx27.dtsi | 2 ++ arch/arm/boot/dts/imx28.dtsi | 1 + arch/arm/boot/dts/imx35.dtsi | 1 + arch/arm/boot/dts/imx50.dtsi | 3 +++ arch/arm/boot/dts/imx51.dtsi | 3 +++ arch/arm/boot/dts/imx53.dtsi | 3 +++ arch/arm/boot/dts/imx6qdl.dtsi | 3 +++ arch/arm/boot/dts/imx6sl.dtsi | 1 + arch/arm/boot/dts/imx6sx.dtsi | 1 + 9 files changed, 18 insertions(+) diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi index 4b063b6..6951b66 100644 --- a/arch/arm/boot/dts/imx27.dtsi +++ b/arch/arm/boot/dts/imx27.dtsi @@ -488,6 +488,7 @@ interrupts = 54; clocks = clks IMX27_CLK_USB_IPG_GATE; fsl,usbmisc = usbmisc 1; + dr_mode = host; status = disabled; }; @@ -497,6 +498,7 @@ interrupts = 55; clocks = clks IMX27_CLK_USB_IPG_GATE; fsl,usbmisc = usbmisc 2; + dr_mode = host; status = disabled; }; diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi index 47f68ac..02330f4 100644 --- a/arch/arm/boot/dts/imx28.dtsi +++ b/arch/arm/boot/dts/imx28.dtsi @@ -1197,6 +1197,7 @@ interrupts = 92; clocks = clks 61; fsl,usbphy = usbphy1; + dr_mode = host; status = disabled; }; diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi index 6932928..b6478e9 100644 --- a/arch/arm/boot/dts/imx35.dtsi +++ b/arch/arm/boot/dts/imx35.dtsi @@ -318,6 +318,7 @@ clocks = clks 73; fsl,usbmisc = usbmisc 1; fsl,usbphy = usbphy1; + dr_mode = host; status = disabled; }; diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi index 620b0f0..e245713 100644 --- a/arch/arm/boot/dts/imx50.dtsi +++ b/arch/arm/boot/dts/imx50.dtsi @@ -197,6 +197,7 @@ reg = 0x53f80200 0x0200; interrupts = 14; clocks = clks IMX5_CLK_USB_PHY2_GATE; + dr_mode = host; status = disabled; }; @@ -205,6 +206,7 @@ reg = 0x53f80400 0x0200; interrupts = 16; clocks = clks IMX5_CLK_USBOH3_GATE; + dr_mode = host; status = disabled; }; @@ -213,6 +215,7 @@ reg = 0x53f80600 0x0200; interrupts = 17; clocks = clks IMX5_CLK_USBOH3_GATE; + dr_mode = host; status = disabled; }; diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi index c0116cf..f46fe9b 100644 --- a/arch/arm/boot/dts/imx51.dtsi +++ b/arch/arm/boot/dts/imx51.dtsi @@ -265,6 +265,7 @@ interrupts = 14; clocks = clks IMX5_CLK_USBOH3_GATE; fsl,usbmisc = usbmisc 1; + dr_mode = host; status = disabled; }; @@ -274,6 +275,7 @@ interrupts = 16; clocks = clks IMX5_CLK_USBOH3_GATE; fsl,usbmisc = usbmisc 2; + dr_mode = host; status = disabled; }; @@ -283,6 +285,7 @@ interrupts = 17; clocks = clks IMX5_CLK_USBOH3_GATE; fsl,usbmisc = usbmisc 3; + dr_mode = host; status = disabled; }; diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi index ff4fa7e..c3e3ca9 100644 --- a/arch/arm/boot/dts/imx53.dtsi +++ b/arch/arm/boot/dts/imx53.dtsi @@ -309,6 +309,7 @@ clocks = clks
[PATCH] Documentation: DT: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be "uart", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = "ti,omap3-uart";
+reg = <0x49042000 0x400>;
+interrupts = <80>;
+dmas = < 81 82>;
+dma-names = "tx", "rx";
+ti,hwmods = "uart4";
+clock-frequency = <4800>;
+};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: DT: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be ti,omap2-uart for OMAP2 controllers
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be uartn, n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : rx for receive channel, tx for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = ti,omap3-uart;
+reg = 0x49042000 0x400;
+interrupts = 80;
+dmas = sdma 81 sdma 82;
+dma-names = tx, rx;
+ti,hwmods = uart4;
+clock-frequency = 4800;
+};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
