Adding MAX1363 to BBB

Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

I don't know if anybody on this list can answer this, we are going to add an IIO compatible Maxim MAX1363 4 channel ADC to our BBB cape and I am not sure how to specify in the dts file that it is connected to the I2C channel.
If anyone can give me suggestions, it would be greatly appreciated.
 
Greg Wilson-Lindberg
Sakura Finetek
310-783-5075

Re: Adding MAX1363 to BBB

[Michael Welling]

On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg Wilson-Lindberg wrote:
> I don't know if anybody on this list can answer this, we are going to add an IIO compatible Maxim MAX1363 4 channel ADC to our BBB cape and I am not sure how to specify in the dts file that it is connected to the I2C channel.
> If anyone can give me suggestions, it would be greatly appreciated.
>  

Give this a try:

&i2c1 {
	status = "okay";

	adc@34 {
		compatible = "maxim,max1363";
		vcc-supply = <&reg_3v3>;
		reg = <0x34>;
	};
};

This assume you have an i2c1 and reg_3v3 defined.

Here is a real example that looks like it uses the same driver:
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts?v=3.14#L56


> Greg Wilson-Lindberg
> Sakura Finetek
> 310-783-5075
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Monday, August 24, 2015 9:55 AM
> To: Greg Wilson-Lindberg
> Cc: linux-iio@vger.kernel.org
> Subject: Re: Adding MAX1363 to BBB
> 
> On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg Wilson-Lindberg wrote:
> > I don't know if anybody on this list can answer this, we 
> are going to add an IIO compatible Maxim MAX1363 4 channel 
> ADC to our BBB cape and I am not sure how to specify in the 
> dts file that it is connected to the I2C channel.
> > If anyone can give me suggestions, it would be greatly appreciated.
> >  
> 
> Give this a try:
> 
> &i2c1 {
> 	status = "okay";
> 
> 	adc@34 {
> 		compatible = "maxim,max1363";
> 		vcc-supply = <&reg_3v3>;
> 		reg = <0x34>;
> 	};
> };
> 
> This assume you have an i2c1 and reg_3v3 defined.

I wasn't sure about specifying the compatible line because the max1363
driver doesn't have a struct of_device_id in it.

> 
> Here is a real example that looks like it uses the same driver:
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> hytec-phycard-s-rdk.dts?v=3.14#L56
> 
> 
> > Greg Wilson-Lindberg
> > Sakura Finetek
> > 310-783-5075
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> 

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Monday, August 24, 2015 9:55 AM
> To: Greg Wilson-Lindberg
> Cc: linux-iio@vger.kernel.org
> Subject: Re: Adding MAX1363 to BBB
> 
> On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg Wilson-Lindberg wrote:
> > I don't know if anybody on this list can answer this, we 
> are going to add an IIO compatible Maxim MAX1363 4 channel 
> ADC to our BBB cape and I am not sure how to specify in the 
> dts file that it is connected to the I2C channel.
> > If anyone can give me suggestions, it would be greatly appreciated.
> >  
> 
> Give this a try:
> 
> &i2c1 {
> 	status = "okay";
> 
> 	adc@34 {
> 		compatible = "maxim,max1363";
> 		vcc-supply = <&reg_3v3>;
> 		reg = <0x34>;
> 	};
> };
> 
> This assume you have an i2c1 and reg_3v3 defined.
> 
> Here is a real example that looks like it uses the same driver:
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> hytec-phycard-s-rdk.dts?v=3.14#L56
> 

I've got the max1363 installed on a board and it is showing up as an I2C device, but not as an IIO device. I used your example above for the dts file.

Any thoughts?

> 
> > Greg Wilson-Lindberg
> > Sakura Finetek
> > 310-783-5075
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Adding MAX1363 to BBB

[Michael Welling]

On Thu, Aug 27, 2015 at 12:10:06PM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Monday, August 24, 2015 9:55 AM
> > To: Greg Wilson-Lindberg
> > Cc: linux-iio@vger.kernel.org
> > Subject: Re: Adding MAX1363 to BBB
> > 
> > On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg Wilson-Lindberg wrote:
> > > I don't know if anybody on this list can answer this, we 
> > are going to add an IIO compatible Maxim MAX1363 4 channel 
> > ADC to our BBB cape and I am not sure how to specify in the 
> > dts file that it is connected to the I2C channel.
> > > If anyone can give me suggestions, it would be greatly appreciated.
> > >  
> > 
> > Give this a try:
> > 
> > &i2c1 {
> > 	status = "okay";
> > 
> > 	adc@34 {
> > 		compatible = "maxim,max1363";
> > 		vcc-supply = <&reg_3v3>;
> > 		reg = <0x34>;
> > 	};
> > };
> > 
> > This assume you have an i2c1 and reg_3v3 defined.
> > 
> > Here is a real example that looks like it uses the same driver:
> > http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> > hytec-phycard-s-rdk.dts?v=3.14#L56
> > 
> 
> I've got the max1363 installed on a board and it is showing up as an I2C device, but not as an IIO device. I used your example above for the dts file.
> 
> Any thoughts?

Try using the following instead:
&i2c1 {
	status = "okay";

	adc@34 {
		compatible = "max1363";
		vcc-supply = <&reg_3v3>;
		reg = <0x34>;
	};
};

> 
> > 
> > > Greg Wilson-Lindberg
> > > Sakura Finetek
> > > 310-783-5075
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe 
> > linux-iio" 
> > > in the body of a message to majordomo@vger.kernel.org More 
> > majordomo 
> > > info at  http://vger.kernel.org/majordomo-info.html
> > 

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 27, 2015 12:16 PM
> To: Greg Wilson-Lindberg
> Cc: linux-iio@vger.kernel.org
> Subject: Re: Adding MAX1363 to BBB
> 
> On Thu, Aug 27, 2015 at 12:10:06PM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Monday, August 24, 2015 9:55 AM
> > > To: Greg Wilson-Lindberg
> > > Cc: linux-iio@vger.kernel.org
> > > Subject: Re: Adding MAX1363 to BBB
> > > 
> > > On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg 
> Wilson-Lindberg wrote:
> > > > I don't know if anybody on this list can answer this, we
> > > are going to add an IIO compatible Maxim MAX1363 4 channel ADC to 
> > > our BBB cape and I am not sure how to specify in the dts 
> file that 
> > > it is connected to the I2C channel.
> > > > If anyone can give me suggestions, it would be greatly 
> appreciated.
> > > >  
> > > 
> > > Give this a try:
> > > 
> > > &i2c1 {
> > > 	status = "okay";
> > > 
> > > 	adc@34 {
> > > 		compatible = "maxim,max1363";
> > > 		vcc-supply = <&reg_3v3>;
> > > 		reg = <0x34>;
> > > 	};
> > > };
> > > 
> > > This assume you have an i2c1 and reg_3v3 defined.
> > > 
> > > Here is a real example that looks like it uses the same driver:
> > > http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> > > hytec-phycard-s-rdk.dts?v=3.14#L56
> > > 
> > 
> > I've got the max1363 installed on a board and it is showing 
> up as an I2C device, but not as an IIO device. I used your 
> example above for the dts file.
> > 
> > Any thoughts?
> 
> Try using the following instead:
> &i2c1 {
> 	status = "okay";
> 
> 	adc@34 {
> 		compatible = "max1363";
> 		vcc-supply = <&reg_3v3>;
> 		reg = <0x34>;
> 	};
> };

I changed the dts to "max1363", but that didn't get it to show up under iio devices.

> 
> > 
> > > 
> > > > Greg Wilson-Lindberg
> > > > Sakura Finetek
> > > > 310-783-5075
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > linux-iio" 
> > > > in the body of a message to majordomo@vger.kernel.org More
> > > majordomo
> > > > info at  http://vger.kernel.org/majordomo-info.html
> > > 
> 

Re: Adding MAX1363 to BBB

[Michael Welling]

On Thu, Aug 27, 2015 at 01:40:24PM -0700, Greg Wilson-Lindberg wrote:
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> > Of Michael Welling
> > Sent: Thursday, August 27, 2015 12:16 PM
> > To: Greg Wilson-Lindberg
> > Cc: linux-iio@vger.kernel.org
> > Subject: Re: Adding MAX1363 to BBB
> > 
> > On Thu, Aug 27, 2015 at 12:10:06PM -0700, Greg Wilson-Lindberg wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > > Michael Welling
> > > > Sent: Monday, August 24, 2015 9:55 AM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: linux-iio@vger.kernel.org
> > > > Subject: Re: Adding MAX1363 to BBB
> > > > 
> > > > On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg 
> > Wilson-Lindberg wrote:
> > > > > I don't know if anybody on this list can answer this, we
> > > > are going to add an IIO compatible Maxim MAX1363 4 channel ADC to 
> > > > our BBB cape and I am not sure how to specify in the dts 
> > file that 
> > > > it is connected to the I2C channel.
> > > > > If anyone can give me suggestions, it would be greatly 
> > appreciated.
> > > > >  
> > > > 
> > > > Give this a try:
> > > > 
> > > > &i2c1 {
> > > > 	status = "okay";
> > > > 
> > > > 	adc@34 {
> > > > 		compatible = "maxim,max1363";
> > > > 		vcc-supply = <&reg_3v3>;
> > > > 		reg = <0x34>;
> > > > 	};
> > > > };
> > > > 
> > > > This assume you have an i2c1 and reg_3v3 defined.
> > > > 
> > > > Here is a real example that looks like it uses the same driver:
> > > > http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> > > > hytec-phycard-s-rdk.dts?v=3.14#L56
> > > > 
> > > 
> > > I've got the max1363 installed on a board and it is showing 
> > up as an I2C device, but not as an IIO device. I used your 
> > example above for the dts file.
> > > 
> > > Any thoughts?
> > 
> > Try using the following instead:
> > &i2c1 {
> > 	status = "okay";
> > 
> > 	adc@34 {
> > 		compatible = "max1363";
> > 		vcc-supply = <&reg_3v3>;
> > 		reg = <0x34>;
> > 	};
> > };
> 
> I changed the dts to "max1363", but that didn't get it to show up under iio devices.
> 

Is the driver compiled into the kernel or a module?

> > 
> > > 
> > > > 
> > > > > Greg Wilson-Lindberg
> > > > > Sakura Finetek
> > > > > 310-783-5075
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-iio" 
> > > > > in the body of a message to majordomo@vger.kernel.org More
> > > > majordomo
> > > > > info at  http://vger.kernel.org/majordomo-info.html
> > > > 
> > 

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Thursday, August 27, 2015 1:42 PM
> To: Greg Wilson-Lindberg
> Cc: linux-iio@vger.kernel.org
> Subject: Re: Adding MAX1363 to BBB
> 
> On Thu, Aug 27, 2015 at 01:40:24PM -0700, Greg Wilson-Lindberg wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Thursday, August 27, 2015 12:16 PM
> > > To: Greg Wilson-Lindberg
> > > Cc: linux-iio@vger.kernel.org
> > > Subject: Re: Adding MAX1363 to BBB
> > > 
> > > On Thu, Aug 27, 2015 at 12:10:06PM -0700, Greg 
> Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] 
> On Behalf Of 
> > > > > Michael Welling
> > > > > Sent: Monday, August 24, 2015 9:55 AM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: linux-iio@vger.kernel.org
> > > > > Subject: Re: Adding MAX1363 to BBB
> > > > > 
> > > > > On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > > I don't know if anybody on this list can answer this, we
> > > > > are going to add an IIO compatible Maxim MAX1363 4 
> channel ADC 
> > > > > to our BBB cape and I am not sure how to specify in the dts
> > > file that
> > > > > it is connected to the I2C channel.
> > > > > > If anyone can give me suggestions, it would be greatly
> > > appreciated.
> > > > > >  
> > > > > 
> > > > > Give this a try:
> > > > > 
> > > > > &i2c1 {
> > > > > 	status = "okay";
> > > > > 
> > > > > 	adc@34 {
> > > > > 		compatible = "maxim,max1363";
> > > > > 		vcc-supply = <&reg_3v3>;
> > > > > 		reg = <0x34>;
> > > > > 	};
> > > > > };
> > > > > 
> > > > > This assume you have an i2c1 and reg_3v3 defined.
> > > > > 
> > > > > Here is a real example that looks like it uses the 
> same driver:
> > > > > http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> > > > > hytec-phycard-s-rdk.dts?v=3.14#L56
> > > > > 
> > > > 
> > > > I've got the max1363 installed on a board and it is showing
> > > up as an I2C device, but not as an IIO device. I used 
> your example 
> > > above for the dts file.
> > > > 
> > > > Any thoughts?
> > > 
> > > Try using the following instead:
> > > &i2c1 {
> > > 	status = "okay";
> > > 
> > > 	adc@34 {
> > > 		compatible = "max1363";
> > > 		vcc-supply = <&reg_3v3>;
> > > 		reg = <0x34>;
> > > 	};
> > > };
> > 
> > I changed the dts to "max1363", but that didn't get it to 
> show up under iio devices.
> > 
> 
> Is the driver compiled into the kernel or a module?

Duh, surprisingly, it was not compiled in at all, that's what I get for thinking everything was enabled.

I compiled it as a module and then I tested it both with the dts set to "max1363" and "maxim,max1363" and lsmod says the module isn't loaded. I think that I'll build the kernel with it compiled in.

> 
> > > 
> > > > 
> > > > > 
> > > > > > Greg Wilson-Lindberg
> > > > > > Sakura Finetek
> > > > > > 310-783-5075
> > > > > > --
> > > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > linux-iio" 
> > > > > > in the body of a message to majordomo@vger.kernel.org More
> > > > > majordomo
> > > > > > info at  http://vger.kernel.org/majordomo-info.html
> > > > > 
> > > 
> 

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: linux-iio-owner@vger.kernel.org 
> [mailto:linux-iio-owner@vger.kernel.org] On Behalf Of Greg 
> Wilson-Lindberg
> Sent: Thursday, August 27, 2015 2:06 PM
> To: Michael Welling
> Cc: linux-iio@vger.kernel.org
> Subject: RE: Adding MAX1363 to BBB
> 
>  
> 
> > -----Original Message-----
> > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > Michael Welling
> > Sent: Thursday, August 27, 2015 1:42 PM
> > To: Greg Wilson-Lindberg
> > Cc: linux-iio@vger.kernel.org
> > Subject: Re: Adding MAX1363 to BBB
> > 
> > On Thu, Aug 27, 2015 at 01:40:24PM -0700, Greg 
> Wilson-Lindberg wrote:
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Michael Welling [mailto:mwelling79@gmail.com] On 
> Behalf Of 
> > > > Michael Welling
> > > > Sent: Thursday, August 27, 2015 12:16 PM
> > > > To: Greg Wilson-Lindberg
> > > > Cc: linux-iio@vger.kernel.org
> > > > Subject: Re: Adding MAX1363 to BBB
> > > > 
> > > > On Thu, Aug 27, 2015 at 12:10:06PM -0700, Greg
> > Wilson-Lindberg wrote:
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Michael Welling [mailto:mwelling79@gmail.com]
> > On Behalf Of
> > > > > > Michael Welling
> > > > > > Sent: Monday, August 24, 2015 9:55 AM
> > > > > > To: Greg Wilson-Lindberg
> > > > > > Cc: linux-iio@vger.kernel.org
> > > > > > Subject: Re: Adding MAX1363 to BBB
> > > > > > 
> > > > > > On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg
> > > > Wilson-Lindberg wrote:
> > > > > > > I don't know if anybody on this list can answer this, we
> > > > > > are going to add an IIO compatible Maxim MAX1363 4
> > channel ADC
> > > > > > to our BBB cape and I am not sure how to specify in the dts
> > > > file that
> > > > > > it is connected to the I2C channel.
> > > > > > > If anyone can give me suggestions, it would be greatly
> > > > appreciated.
> > > > > > >  
> > > > > > 
> > > > > > Give this a try:
> > > > > > 
> > > > > > &i2c1 {
> > > > > > 	status = "okay";
> > > > > > 
> > > > > > 	adc@34 {
> > > > > > 		compatible = "maxim,max1363";
> > > > > > 		vcc-supply = <&reg_3v3>;
> > > > > > 		reg = <0x34>;
> > > > > > 	};
> > > > > > };
> > > > > > 
> > > > > > This assume you have an i2c1 and reg_3v3 defined.
> > > > > > 
> > > > > > Here is a real example that looks like it uses the
> > same driver:
> > > > > > 
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> > > > > > hytec-phycard-s-rdk.dts?v=3.14#L56
> > > > > > 
> > > > > 
> > > > > I've got the max1363 installed on a board and it is showing
> > > > up as an I2C device, but not as an IIO device. I used
> > your example
> > > > above for the dts file.
> > > > > 
> > > > > Any thoughts?
> > > > 
> > > > Try using the following instead:
> > > > &i2c1 {
> > > > 	status = "okay";
> > > > 
> > > > 	adc@34 {
> > > > 		compatible = "max1363";
> > > > 		vcc-supply = <&reg_3v3>;
> > > > 		reg = <0x34>;
> > > > 	};
> > > > };
> > > 
> > > I changed the dts to "max1363", but that didn't get it to
> > show up under iio devices.
> > > 
> > 
> > Is the driver compiled into the kernel or a module?
> 
> Duh, surprisingly, it was not compiled in at all, that's what 
> I get for thinking everything was enabled.
> 
> I compiled it as a module and then I tested it both with the 
> dts set to "max1363" and "maxim,max1363" and lsmod says the 
> module isn't loaded. I think that I'll build the kernel with 
> it compiled in.
> 

I compiled in the max1363 and tsadc drivers (and IIO subsystem) and with the dts set to "maxim,max1363" the max1363 is showing up as /sys/devices/ocp/4819c000.i2c/i2c-2/2-0034/iio:device0.

So now all I have to do is get the read routines working with it.

Again, thanks for all of your help.

> > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > Greg Wilson-Lindberg
> > > > > > > Sakura Finetek
> > > > > > > 310-783-5075
> > > > > > > --
> > > > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > > linux-iio" 
> > > > > > > in the body of a message to majordomo@vger.kernel.org More
> > > > > > majordomo
> > > > > > > info at  http://vger.kernel.org/majordomo-info.html
> > > > > > 
> > > > 
> > --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Greg Wilson-Lindberg 
> Sent: Thursday, August 27, 2015 2:44 PM
> To: Greg Wilson-Lindberg; Michael Welling
> Cc: linux-iio@vger.kernel.org
> Subject: RE: Adding MAX1363 to BBB
> 
>  
> 
> > -----Original Message-----
> > From: linux-iio-owner@vger.kernel.org 
> > [mailto:linux-iio-owner@vger.kernel.org] On Behalf Of Greg 
> > Wilson-Lindberg
> > Sent: Thursday, August 27, 2015 2:06 PM
> > To: Michael Welling
> > Cc: linux-iio@vger.kernel.org
> > Subject: RE: Adding MAX1363 to BBB
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> > > Michael Welling
> > > Sent: Thursday, August 27, 2015 1:42 PM
> > > To: Greg Wilson-Lindberg
> > > Cc: linux-iio@vger.kernel.org
> > > Subject: Re: Adding MAX1363 to BBB
> > > 
> > > On Thu, Aug 27, 2015 at 01:40:24PM -0700, Greg
> > Wilson-Lindberg wrote:
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Michael Welling [mailto:mwelling79@gmail.com] On
> > Behalf Of
> > > > > Michael Welling
> > > > > Sent: Thursday, August 27, 2015 12:16 PM
> > > > > To: Greg Wilson-Lindberg
> > > > > Cc: linux-iio@vger.kernel.org
> > > > > Subject: Re: Adding MAX1363 to BBB
> > > > > 
> > > > > On Thu, Aug 27, 2015 at 12:10:06PM -0700, Greg
> > > Wilson-Lindberg wrote:
> > > > > >  
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Michael Welling [mailto:mwelling79@gmail.com]
> > > On Behalf Of
> > > > > > > Michael Welling
> > > > > > > Sent: Monday, August 24, 2015 9:55 AM
> > > > > > > To: Greg Wilson-Lindberg
> > > > > > > Cc: linux-iio@vger.kernel.org
> > > > > > > Subject: Re: Adding MAX1363 to BBB
> > > > > > > 
> > > > > > > On Mon, Aug 24, 2015 at 09:26:53AM -0700, Greg
> > > > > Wilson-Lindberg wrote:
> > > > > > > > I don't know if anybody on this list can answer this, we
> > > > > > > are going to add an IIO compatible Maxim MAX1363 4
> > > channel ADC
> > > > > > > to our BBB cape and I am not sure how to specify 
> in the dts
> > > > > file that
> > > > > > > it is connected to the I2C channel.
> > > > > > > > If anyone can give me suggestions, it would be greatly
> > > > > appreciated.
> > > > > > > >  
> > > > > > > 
> > > > > > > Give this a try:
> > > > > > > 
> > > > > > > &i2c1 {
> > > > > > > 	status = "okay";
> > > > > > > 
> > > > > > > 	adc@34 {
> > > > > > > 		compatible = "maxim,max1363";
> > > > > > > 		vcc-supply = <&reg_3v3>;
> > > > > > > 		reg = <0x34>;
> > > > > > > 	};
> > > > > > > };
> > > > > > > 
> > > > > > > This assume you have an i2c1 and reg_3v3 defined.
> > > > > > > 
> > > > > > > Here is a real example that looks like it uses the
> > > same driver:
> > > > > > > 
> > http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx27-p
> > > > > > > hytec-phycard-s-rdk.dts?v=3.14#L56
> > > > > > > 
> > > > > > 
> > > > > > I've got the max1363 installed on a board and it is showing
> > > > > up as an I2C device, but not as an IIO device. I used
> > > your example
> > > > > above for the dts file.
> > > > > > 
> > > > > > Any thoughts?
> > > > > 
> > > > > Try using the following instead:
> > > > > &i2c1 {
> > > > > 	status = "okay";
> > > > > 
> > > > > 	adc@34 {
> > > > > 		compatible = "max1363";
> > > > > 		vcc-supply = <&reg_3v3>;
> > > > > 		reg = <0x34>;
> > > > > 	};
> > > > > };
> > > > 
> > > > I changed the dts to "max1363", but that didn't get it to
> > > show up under iio devices.
> > > > 
> > > 
> > > Is the driver compiled into the kernel or a module?
> > 
> > Duh, surprisingly, it was not compiled in at all, that's what I get 
> > for thinking everything was enabled.
> > 
> > I compiled it as a module and then I tested it both with 
> the dts set 
> > to "max1363" and "maxim,max1363" and lsmod says the module isn't 
> > loaded. I think that I'll build the kernel with it compiled in.
> > 
> 
> I compiled in the max1363 and tsadc drivers (and IIO 
> subsystem) and with the dts set to "maxim,max1363" the 
> max1363 is showing up as 
> /sys/devices/ocp/4819c000.i2c/i2c-2/2-0034/iio:device0.
> 
> So now all I have to do is get the read routines working with it.
> 
> Again, thanks for all of your help.
> 

I've got the system running, but I get an invalid argument error on the call to iio_buffer_refill().  I'm basically using the same code as for the tsadc, just added in a fourth channel, and none of the setup calls are returning errors, but the first iio_buffer_refill() call returns an error.  I've dumped out the parameter that is being passed to the iio_buffer_refill() call and it is the same as the value that was returned from the iio_device_create_buffer() call.

I've looked at the libiio source and I don't see anything obvious that should return invalid argument for the iio_buffer_refill() call.


> > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > Greg Wilson-Lindberg
> > > > > > > > Sakura Finetek
> > > > > > > > 310-783-5075
> > > > > > > > --
> > > > > > > > To unsubscribe from this list: send the line 
> "unsubscribe
> > > > > > > linux-iio" 
> > > > > > > > in the body of a message to 
> majordomo@vger.kernel.org More
> > > > > > > majordomo
> > > > > > > > info at  http://vger.kernel.org/majordomo-info.html
> > > > > > > 
> > > > > 
> > > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at http://vger.kernel.org/majordomo-info.html
> > 

Re: Adding MAX1363 to BBB

[Michael Welling]

On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg Wilson-Lindberg wrote:
> 
> I've got the system running, but I get an invalid argument error on the call to iio_buffer_refill().  I'm basically using the same code as for the tsadc, just added in a fourth channel, and none of the setup calls are returning errors, but the first iio_buffer_refill() call returns an error.  I've dumped out the parameter that is being passed to the iio_buffer_refill() call and it is the same as the value that was returned from the iio_device_create_buffer() call.
> 
> I've looked at the libiio source and I don't see anything obvious that should return invalid argument for the iio_buffer_refill() call.
>

I believe that you need to register an interrupt for buffered access to work.

Do you have an interrupt connected and registered?

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> Of Michael Welling
> Sent: Friday, August 28, 2015 5:32 PM
> To: Greg Wilson-Lindberg
> Cc: linux-iio@vger.kernel.org
> Subject: Re: Adding MAX1363 to BBB
> 
> On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg Wilson-Lindberg wrote:
> > 
> > I've got the system running, but I get an invalid argument 
> error on the call to iio_buffer_refill().  I'm basically 
> using the same code as for the tsadc, just added in a fourth 
> channel, and none of the setup calls are returning errors, 
> but the first iio_buffer_refill() call returns an error.  
> I've dumped out the parameter that is being passed to the 
> iio_buffer_refill() call and it is the same as the value that 
> was returned from the iio_device_create_buffer() call.
> > 
> > I've looked at the libiio source and I don't see anything 
> obvious that should return invalid argument for the 
> iio_buffer_refill() call.
> >
> 
> I believe that you need to register an interrupt for buffered 
> access to work.
> 
> Do you have an interrupt connected and registered?
> 

Nope, no interrupt.  So I guess I would need to ask, how would I register the interrupt in the Device Tree?

Or, alternatively, can I just get individual readings through IIO?
 

Re: Adding MAX1363 to BBB

[Jonathan Cameron]

On 31/08/15 17:01, Greg Wilson-Lindberg wrote:
>  
> 
>> -----Original Message-----
>> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
>> Of Michael Welling
>> Sent: Friday, August 28, 2015 5:32 PM
>> To: Greg Wilson-Lindberg
>> Cc: linux-iio@vger.kernel.org
>> Subject: Re: Adding MAX1363 to BBB
>>
>> On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg Wilson-Lindberg wrote:
>>>
>>> I've got the system running, but I get an invalid argument 
>> error on the call to iio_buffer_refill().  I'm basically 
>> using the same code as for the tsadc, just added in a fourth 
>> channel, and none of the setup calls are returning errors, 
>> but the first iio_buffer_refill() call returns an error.  
>> I've dumped out the parameter that is being passed to the 
>> iio_buffer_refill() call and it is the same as the value that 
>> was returned from the iio_device_create_buffer() call.
>>>
>>> I've looked at the libiio source and I don't see anything 
>> obvious that should return invalid argument for the 
>> iio_buffer_refill() call.
>>>
>>
>> I believe that you need to register an interrupt for buffered 
>> access to work.
>>
>> Do you have an interrupt connected and registered?
>>
> 
> Nope, no interrupt.  So I guess I would need to ask, how would I register the interrupt in the Device Tree?
The max1363 (and similar) don't have a dataready interrupt as they
are clocked of the actual clock cycles of the i2c transfers.  So
they only read on demand.

> 
> Or, alternatively, can I just get individual readings through IIO?
Either via sysfs, or by adding a sysfs trigger and poking that.
To add a sysfs trigger you'll need to probe the module, then poke
a number into the add_trigger attribute to create a trigger which can
then be associated with the max1363 (as normal).

Then to 'fire' the trigger write to the trigger_now attribute of the
relevant trigger.

Ideally Daniel will be back soonish with a final version of the
high resolution timer trigger that would also work well here.
(it's rather tied up with some configfs support which wis
trickier!).

Jonathan
>  --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Adding MAX1363 to BBB

[Michael Welling]

On Mon, Aug 31, 2015 at 05:24:21PM +0100, Jonathan Cameron wrote:
> On 31/08/15 17:01, Greg Wilson-Lindberg wrote:
> >  
> > 
> >> -----Original Message-----
> >> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
> >> Of Michael Welling
> >> Sent: Friday, August 28, 2015 5:32 PM
> >> To: Greg Wilson-Lindberg
> >> Cc: linux-iio@vger.kernel.org
> >> Subject: Re: Adding MAX1363 to BBB
> >>
> >> On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg Wilson-Lindberg wrote:
> >>>
> >>> I've got the system running, but I get an invalid argument 
> >> error on the call to iio_buffer_refill().  I'm basically 
> >> using the same code as for the tsadc, just added in a fourth 
> >> channel, and none of the setup calls are returning errors, 
> >> but the first iio_buffer_refill() call returns an error.  
> >> I've dumped out the parameter that is being passed to the 
> >> iio_buffer_refill() call and it is the same as the value that 
> >> was returned from the iio_device_create_buffer() call.
> >>>
> >>> I've looked at the libiio source and I don't see anything 
> >> obvious that should return invalid argument for the 
> >> iio_buffer_refill() call.
> >>>
> >>
> >> I believe that you need to register an interrupt for buffered 
> >> access to work.
> >>
> >> Do you have an interrupt connected and registered?
> >>
> > 
> > Nope, no interrupt.  So I guess I would need to ask, how would I register the interrupt in the Device Tree?
> The max1363 (and similar) don't have a dataready interrupt as they
> are clocked of the actual clock cycles of the i2c transfers.  So
> they only read on demand.
>

Ah, yes. Looking at the datasheet the interrupt is triggered by a window
comparator not end of sample.

> > 
> > Or, alternatively, can I just get individual readings through IIO?
> Either via sysfs, or by adding a sysfs trigger and poking that.
> To add a sysfs trigger you'll need to probe the module, then poke
> a number into the add_trigger attribute to create a trigger which can
> then be associated with the max1363 (as normal).
> 
> Then to 'fire' the trigger write to the trigger_now attribute of the
> relevant trigger.
> 
> Ideally Daniel will be back soonish with a final version of the
> high resolution timer trigger that would also work well here.
> (it's rather tied up with some configfs support which wis
> trickier!).

It is probably easiest to sample using sysfs directly.

This would be same as the last method we tried while trying to
access to TI ADC and touchscreen simultaneously.

http://www.spinics.net/lists/linux-iio/msg20577.html

> 
> Jonathan
> >  --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

Re: Adding MAX1363 to BBB

[Jonathan Cameron]

On 31/08/15 17:52, Michael Welling wrote:
> On Mon, Aug 31, 2015 at 05:24:21PM +0100, Jonathan Cameron wrote:
>> On 31/08/15 17:01, Greg Wilson-Lindberg wrote:
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf 
>>>> Of Michael Welling
>>>> Sent: Friday, August 28, 2015 5:32 PM
>>>> To: Greg Wilson-Lindberg
>>>> Cc: linux-iio@vger.kernel.org
>>>> Subject: Re: Adding MAX1363 to BBB
>>>>
>>>> On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg Wilson-Lindberg wrote:
>>>>>
>>>>> I've got the system running, but I get an invalid argument 
>>>> error on the call to iio_buffer_refill().  I'm basically 
>>>> using the same code as for the tsadc, just added in a fourth 
>>>> channel, and none of the setup calls are returning errors, 
>>>> but the first iio_buffer_refill() call returns an error.  
>>>> I've dumped out the parameter that is being passed to the 
>>>> iio_buffer_refill() call and it is the same as the value that 
>>>> was returned from the iio_device_create_buffer() call.
>>>>>
>>>>> I've looked at the libiio source and I don't see anything 
>>>> obvious that should return invalid argument for the 
>>>> iio_buffer_refill() call.
>>>>>
>>>>
>>>> I believe that you need to register an interrupt for buffered 
>>>> access to work.
>>>>
>>>> Do you have an interrupt connected and registered?
>>>>
>>>
>>> Nope, no interrupt.  So I guess I would need to ask, how would I register the interrupt in the Device Tree?
>> The max1363 (and similar) don't have a dataready interrupt as they
>> are clocked of the actual clock cycles of the i2c transfers.  So
>> they only read on demand.
>>
> 
> Ah, yes. Looking at the datasheet the interrupt is triggered by a window
> comparator not end of sample.
That takes me back. It was one of my first drivers ;)  They monitor
stuff is real pain as it does output normal readings when monitor
is running but only after a whole load of other stuff.  I think I got
lazy and decided not to unwind that but just to make the driver not
read the channels when monitor was enabled.

> 
>>>
>>> Or, alternatively, can I just get individual readings through IIO?
>> Either via sysfs, or by adding a sysfs trigger and poking that.
>> To add a sysfs trigger you'll need to probe the module, then poke
>> a number into the add_trigger attribute to create a trigger which can
>> then be associated with the max1363 (as normal).
>>
>> Then to 'fire' the trigger write to the trigger_now attribute of the
>> relevant trigger.
>>
>> Ideally Daniel will be back soonish with a final version of the
>> high resolution timer trigger that would also work well here.
>> (it's rather tied up with some configfs support which wis
>> trickier!).
> 
> It is probably easiest to sample using sysfs directly.
> 
> This would be same as the last method we tried while trying to
> access to TI ADC and touchscreen simultaneously.
> 
> http://www.spinics.net/lists/linux-iio/msg20577.html
That should work fine.

Jonathan
> 
>>
>> Jonathan
>>>  --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: Adding MAX1363 to BBB

[Greg Wilson-Lindberg]

 

> -----Original Message-----
> From: Jonathan Cameron [mailto:jic23@kernel.org] 
> Sent: Monday, August 31, 2015 9:56 AM
> To: Michael Welling
> Cc: Greg Wilson-Lindberg; linux-iio@vger.kernel.org; Daniel Baluta
> Subject: Re: Adding MAX1363 to BBB
> 
> On 31/08/15 17:52, Michael Welling wrote:
> > On Mon, Aug 31, 2015 at 05:24:21PM +0100, Jonathan Cameron wrote:
> >> On 31/08/15 17:01, Greg Wilson-Lindberg wrote:
> >>>  
> >>>
> >>>> -----Original Message-----
> >>>> From: Michael Welling [mailto:mwelling79@gmail.com] On Behalf Of 
> >>>> Michael Welling
> >>>> Sent: Friday, August 28, 2015 5:32 PM
> >>>> To: Greg Wilson-Lindberg
> >>>> Cc: linux-iio@vger.kernel.org
> >>>> Subject: Re: Adding MAX1363 to BBB
> >>>>
> >>>> On Fri, Aug 28, 2015 at 04:56:20PM -0700, Greg 
> Wilson-Lindberg wrote:
> >>>>>
> >>>>> I've got the system running, but I get an invalid argument
> >>>> error on the call to iio_buffer_refill().  I'm basically 
> using the 
> >>>> same code as for the tsadc, just added in a fourth channel, and 
> >>>> none of the setup calls are returning errors, but the first 
> >>>> iio_buffer_refill() call returns an error.
> >>>> I've dumped out the parameter that is being passed to the
> >>>> iio_buffer_refill() call and it is the same as the value 
> that was 
> >>>> returned from the iio_device_create_buffer() call.
> >>>>>
> >>>>> I've looked at the libiio source and I don't see anything
> >>>> obvious that should return invalid argument for the
> >>>> iio_buffer_refill() call.
> >>>>>
> >>>>
> >>>> I believe that you need to register an interrupt for buffered 
> >>>> access to work.
> >>>>
> >>>> Do you have an interrupt connected and registered?
> >>>>
> >>>
> >>> Nope, no interrupt.  So I guess I would need to ask, how 
> would I register the interrupt in the Device Tree?
> >> The max1363 (and similar) don't have a dataready interrupt as they 
> >> are clocked of the actual clock cycles of the i2c 
> transfers.  So they 
> >> only read on demand.
> >>
> > 
> > Ah, yes. Looking at the datasheet the interrupt is triggered by a 
> > window comparator not end of sample.
> That takes me back. It was one of my first drivers ;)  They 
> monitor stuff is real pain as it does output normal readings 
> when monitor is running but only after a whole load of other 
> stuff.  I think I got lazy and decided not to unwind that but 
> just to make the driver not read the channels when monitor 
> was enabled.

Not a problem, we don't need the monitor function.

> 
> > 
> >>>
> >>> Or, alternatively, can I just get individual readings through IIO?
> >> Either via sysfs, or by adding a sysfs trigger and poking that.
> >> To add a sysfs trigger you'll need to probe the module, 
> then poke a 
> >> number into the add_trigger attribute to create a trigger 
> which can 
> >> then be associated with the max1363 (as normal).
> >>
> >> Then to 'fire' the trigger write to the trigger_now 
> attribute of the 
> >> relevant trigger.
> >>
> >> Ideally Daniel will be back soonish with a final version 
> of the high 
> >> resolution timer trigger that would also work well here.
> >> (it's rather tied up with some configfs support which wis 
> trickier!).
> > 
> > It is probably easiest to sample using sysfs directly.
> > 
> > This would be same as the last method we tried while trying 
> to access 
> > to TI ADC and touchscreen simultaneously.
> > 
> > http://www.spinics.net/lists/linux-iio/msg20577.html
> That should work fine.

I'm converting back to that style, I should have it running in a bit.
Greg

> 
> Jonathan
> > 
> >>
> >> Jonathan
> >>>  --
> >>> To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" 
> >>> in the body of a message to majordomo@vger.kernel.org 
> More majordomo 
> >>> info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-iio" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
>