i2c driver for imx23 is included in kernel 3.x. To add i2c support on
olinuxino needed to patch kernel source with patch available here:
https://www.dropbox.com/s/v9z0q9mkmoa5vsm/0001-MXS-imx23-olinuxino-Add-i2c-support.patch (https://www.dropbox.com/s/v9z0q9mkmoa5vsm/0001-MXS-imx23-olinuxino-Add-i2c-support.patch)
Following code define i2c support on olinuxino:
i2c0: i2c@80058000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
};
Example-1: MOD-IO2 boardMOD-IO2 has i2c interface to connect external RELAYs and GPIOs to any boards with UEXT connector.
Test is done with kernel 3.7.0-rc3-next-20121102-dirty and utility i2c-tool available from Olimex web site.
To activate both relays, run command:
./i2c-tool -w 0 0x48 4 0x02 0xA0 0x40 0x03
here is response:
SLAVE ADDRESS: 0x48
NUMBER OF BYTES TO WRITE: 4
MEMORY ALLOCATED AT ADDRESS: 0x743008
/dev/i2c-0 OPENDED!
WRITE:SUCCESS
to deactivate relays, run:
./i2c-tool -w 0 0x48 4 0x02 0xA0 0x40 0x00
response:
SLAVE ADDRESS: 0x48
NUMBER OF BYTES TO WRITE: 4
MEMORY ALLOCATED AT ADDRESS: 0x1DAC008
/dev/i2c-0 OPENDED!
WRITE:SUCCESS
Following photo shown olinuxino-mini MOD-IO2 with activated relays:
If device attached on i2c UEXT connector need linux driver, previous code need to adapted by end user.
Example-2: EEPROM atmel,24c128
i2c0: i2c@80058000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
eeprom: eeprom@51 {
compatible = "atmel,24c128";
reg = <0x51>;
pagesize = <32>;
};
};
AcknowledgementsFabio Estevam, Freescale; Providing assistance and guidance in development of i2c patch
Tsvetan Usunov, Olimex: Providing hardware for testing of i2c interface
Fadil Berisha
Amazing! Big THANKS for your efforts, if you need any other hardware you need to test/play with just let me know ;)
So now we have in 3.x: SPI, I2C, UART, USB, SD-card, GPIOs and only LRADC, Audio and Video left unimplemented from all features iMX233 have?
LRADC is already supported in 3.7-rc4.
Regards,
Fabio Estevam
Hi,
When applied to linux-3.7-rc5 /dev/i2c-0 appeared. I have some questions now.
Quote from: Fadil Berisha on November 07, 2012, 06:03:18 AM
If device attached on i2c UEXT connector need linux driver, previous code need to adapted by end user.
Example-2: EEPROM atmel,24c128
i2c0: i2c@80058000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
eeprom: eeprom@51 {
compatible = "atmel,24c128";
reg = <0x51>;
pagesize = <32>;
};
};
Is changing imx23.dtsi and/or imx23-olinuxino.dts file necssary whenever I change connected devices, or only when such device need to load external module?
Let's say that I have PCF8574 device and I want to use Write/read operations only (eg. using olimex' i2c-tool or my own dedicated program). Must I change device tree files?
What is needed to get i2cdetect working? For now it says 'Error: Can't use SMBus Quick Write command on this bus'.
Thank you in advance, Robert
Quote from: robwoj on November 14, 2012, 11:24:52 AM
Is changing imx23.dtsi and/or imx23-olinuxino.dts file necssary whenever I change connected devices,
1. If device does not require driver - no need to change files,
2. If device need driver - need to change only imx23-olinuxino.dts file:
i2c0: i2c@80058000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
/* Add node for slave device here, e.g. PCF8574 */
};
Compile new DT file and append DT file on kernel. For procedure see https://github.com/koliqi/imx23-olinuxino
Fadil Berisha
Hi,
I've some issues with i2c-tools.
Tested with linux-next git (3.8.0-rc1) and your modifications.
Now when I scan the i2c bus I've no longer error message about SMBUS.
But, after scanning address 0x30, I've got some errors about PIO reg.
Fadil, have you try scanning with i2c-tools ?
Maybe is DMA who are not ready ? (http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-mxs.c#L217)
[79108.240000] i2c i2c-0: master_xfer[0] W, addr=0x25, len=0
[79108.250000] mxs-i2c 80058000.i2c: addr: 0x0025, len: 0, flags: 0x0, stop: 1
[79108.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x26
[79108.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.250000] i2c i2c-0: master_xfer[0] W, addr=0x26, len=0
[79108.260000] mxs-i2c 80058000.i2c: addr: 0x0026, len: 0, flags: 0x0, stop: 1
[79108.260000] i2c i2c-0: ioctl, cmd=0x703, arg=0x27
[79108.260000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.260000] i2c i2c-0: master_xfer[0] W, addr=0x27, len=0
[79108.270000] mxs-i2c 80058000.i2c: addr: 0x0027, len: 0, flags: 0x0, stop: 1
[79108.270000] i2c i2c-0: ioctl, cmd=0x703, arg=0x28
[79108.270000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.270000] i2c i2c-0: master_xfer[0] W, addr=0x28, len=0
[79108.280000] mxs-i2c 80058000.i2c: addr: 0x0028, len: 0, flags: 0x0, stop: 1
[79108.280000] i2c i2c-0: ioctl, cmd=0x703, arg=0x29
[79108.280000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.280000] i2c i2c-0: master_xfer[0] W, addr=0x29, len=0
[79108.290000] mxs-i2c 80058000.i2c: addr: 0x0029, len: 0, flags: 0x0, stop: 1
[79108.290000] i2c i2c-0: ioctl, cmd=0x703, arg=0x2a
[79108.290000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.290000] i2c i2c-0: master_xfer[0] W, addr=0x2a, len=0
[79108.300000] mxs-i2c 80058000.i2c: addr: 0x002a, len: 0, flags: 0x0, stop: 1
[79108.300000] i2c i2c-0: ioctl, cmd=0x703, arg=0x2b
[79108.300000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.300000] i2c i2c-0: master_xfer[0] W, addr=0x2b, len=0
[79108.310000] mxs-i2c 80058000.i2c: addr: 0x002b, len: 0, flags: 0x0, stop: 1
[79108.310000] i2c i2c-0: ioctl, cmd=0x703, arg=0x2c
[79108.310000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.310000] i2c i2c-0: master_xfer[0] W, addr=0x2c, len=0
[79108.320000] mxs-i2c 80058000.i2c: addr: 0x002c, len: 0, flags: 0x0, stop: 1
[79108.320000] i2c i2c-0: ioctl, cmd=0x703, arg=0x2d
[79108.320000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.320000] i2c i2c-0: master_xfer[0] W, addr=0x2d, len=0
[79108.330000] mxs-i2c 80058000.i2c: addr: 0x002d, len: 0, flags: 0x0, stop: 1
[79108.330000] i2c i2c-0: ioctl, cmd=0x703, arg=0x2e
[79108.330000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.330000] i2c i2c-0: master_xfer[0] W, addr=0x2e, len=0
[79108.340000] mxs-i2c 80058000.i2c: addr: 0x002e, len: 0, flags: 0x0, stop: 1
[79108.340000] i2c i2c-0: ioctl, cmd=0x703, arg=0x2f
[79108.340000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.340000] i2c i2c-0: master_xfer[0] W, addr=0x2f, len=0
[79108.350000] mxs-i2c 80058000.i2c: addr: 0x002f, len: 0, flags: 0x0, stop: 1
[79108.360000] i2c i2c-0: ioctl, cmd=0x703, arg=0x30
[79108.360000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.360000] i2c i2c-0: master_xfer[0] R, addr=0x30, len=1
[79108.370000] mxs-i2c 80058000.i2c: addr: 0x0030, len: 1, flags: 0x1, stop: 1
[79108.380000] mxs-i2c 80058000.i2c: Failed to get PIO reg. write descriptor.
[79108.380000] i2c i2c-0: ioctl, cmd=0x703, arg=0x31
[79108.380000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79108.380000] i2c i2c-0: master_xfer[0] R, addr=0x31, len=1
[79108.390000] mxs-i2c 80058000.i2c: addr: 0x0031, len: 1, flags: 0x1, stop: 1
[79109.410000] mxs-i2c 80058000.i2c: Timeout!
[79109.410000] i2c i2c-0: ioctl, cmd=0x703, arg=0x32
[79109.410000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79109.410000] i2c i2c-0: master_xfer[0] R, addr=0x32, len=1
[79109.420000] mxs-i2c 80058000.i2c: addr: 0x0032, len: 1, flags: 0x1, stop: 1
[79109.430000] mxs-i2c 80058000.i2c: Failed to get PIO reg. write descriptor.
[79109.430000] i2c i2c-0: ioctl, cmd=0x703, arg=0x33
[79109.430000] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeb57c8c
[79109.430000] i2c i2c-0: master_xfer[0] R, addr=0x33, len=1
[79109.440000] mxs-i2c 80058000.i2c: addr: 0x0033, len: 1, flags: 0x1, stop: 1
[79110.460000] mxs-i2c 80058000.i2c: Timeout!
Hi Niii
Test is done with kernel 3.7.0-rc3-next-20121102 and 3.7.1-stable using utility i2c-tool available from Olimex web site (found in software package of MOD-IO2). i2c-tool working very well so I didn't had need to try another tool.
Fadil Berisha
Fadil,
Have you a copy of your precompiled i2c-tool binary somewhere ?
I don't have windows OS with me at this time for compilation :/.
Thanks.
Hi all,
I'm having trouble also with i2c. Specifically, a read or write results in either EINVAL with a kernel error "mxs-i2c 80058000.i2c: Failed to get PIO reg. write descriptor", or ETIMEDOUT, when using "i2c-tool -w ..." or "i2c-tool -r ...".
Output from strace:
...
open("/dev/i2c-0", O_RDWR) = 3
write(1, "/dev/i2c-0 OPENDED!\n", 20/dev/i2c-0 OPENDED!
) = 20
ioctl(3, 0x703, 0x18) = 0
write(3, " '", 2) = -1 ETIMEDOUT (Connection timed out)
...
Or:
...
open("/dev/i2c-0", O_RDWR) = 3
write(1, "/dev/i2c-0 OPENDED!\n", 20/dev/i2c-0 OPENDED!
) = 20
ioctl(3, 0x703, 0x18) = 0
write(3, " '", 2) = -1 EINVAL (Invalid argument)
...
I know the device (LSM303 compass/accel) works, it has been tested with other hardware.
There appears no signal on the SCL pin when I attach a scope.
I have tried the stock kernel that comes with the Arch linux image (http://archlinuxarm.org/platforms/armv5/olinuxino) which is 3.7.2, and also 3.7.1 patched and compiled per instructions in https://github.com/koliqi/imx23-olinuxino.
I would appreciate any help or pointers anyone has.
Thanks,
-harold
Hi,
Can you try this patch (tested on 3.8.0-rc3) :
https://www.dropbox.com/s/3jl58z6av6yfzwl/i2c_dma_reg-imx233_fix.patch
Source : http://permalink.gmane.org/gmane.linux.drivers.i2c/13798
It fix error on PIO and imx233 registers.
But your i2c hw bus will works only with "Read byte" commands(i2cdetect -r).
I've got nothing too with quick probe on my scope, it seems to be not supported (no reference in imx233 datasheet)
Nicolas
Quote from: Niii on January 19, 2013, 12:53:27 PM
Hi,
Can you try this patch (tested on 3.8.0-rc3) :
Excellent work. No more "Failed to get PIO reg. write descriptor" error when tested with i2cdetect. My applaud and Karma +1
Fadil Berisha
Hi Niii,
Thanks I will try this with 3.8. Did you apply the new patch over the old ones or just this patch alone?
Are you saying i2c now actually works, albeit only in "read byte" mode?
Thanks,
-harold
Hi Harold,
Try this :
Just before compile your kernel, apply these three patchs :
1) Same as Fadil patch, but set compatibily for i2c0 to imx23 instead imx28.
https://www.dropbox.com/s/r6quykxgozuwiak/i2c_mxs-dts.patch
2) Patch from Marex with a minor fix (now INIT_COMPLETION is lowercase in driver, so hunk 4 fail with original patch).
https://www.dropbox.com/s/v07eehulrc4dv18/i2c_mxs-dma.patch
3) Patch for set correctly registers for imx23.
https://www.dropbox.com/s/pvbt9d883de0m6v/i2c_mxs-reg.patch
With Fadil, all mode works on 3.8.0-rc3.
For me, scan only works with -r option, and 50% scan bus fail at error -110.
I need to take a look at that.
Nicolas
Ps : For information i2c bus is on pins 23/24 CON1, and you need to solder jumpers for HW i2c (Micro manual section 6.11.1)
Hi,
I just made a patch to test debugfs, if someone wanna try :
https://www.dropbox.com/s/tdzhzmokpdqzkuw/i2c_mxs-debugfs.patch
Before a scan :
root@micro:~# cat /sys/kernel/debug/mxs-i2c/regs
MXS_I2C_DATA: 0x00000000
MXS_I2C_DEBUG0: 0x00100000
MXS_I2C_DEBUG0_CLR: 0x00100000
After a scan :
root@micro:~# cat /sys/kernel/debug/mxs-i2c/regs
MXS_I2C_DATA: 0x00000015
MXS_I2C_DEBUG0: 0x0010d000
MXS_I2C_DEBUG0_CLR: 0x0010d000
Nicolas
Hi Nicholas,
I have tried your suggested patches on 3.8-rc3, and I can get a response sometimes. Alternate times it times out (errno = ETIMEDOUT = 110) as you observed.
Also if I read a larger buffer, I get:
[ 363.140000] INFO: trying to register non-static key.
[ 363.140000] the code is fine but needs lockdep annotation.
[ 363.140000] turning off the locking correctness validator.
followed by an oops.
Is there any way to avoid the ETIMEOUT?
Thanks,
-harold
>Is there any way to avoid the ETIMEOUT?
For moment I don't know how.
I'm trying to found if there a relation about this and status registers.
But I don't understand why you and me have -110 error, and nothing for Fadil .
Update : Fadil has error -110 too.
There is a timeout error because of function mxs_i2c_pio_wait_dmareq() from i2c-mxs.c.
Sometimes bit 31(DMAREQ) in HW_I2C_DEBUG0 register (25.4.8 p1140) is set to 0, but for no error it should be 1.
I don't know why at this time ...
Well, with a bus reset after a success command I've no timeout error.
Error is after select command in function mxs_i2c_pio_setup_xfer() :
writel(MXS_I2C_CTRL0_RUN | MXS_CMD_I2C_SELECT, i2c->regs + MXS_I2C_CTRL0);
After this command the bit 31(DMAREQ) in HW_I2C_DEBUG0 should be 1, but sometimes it's 0, I don't know why ...
Maybe it's a ugly fix, but I reach my limit into debugging :)
Timeout patch :
https://www.dropbox.com/s/r4kling4kf8dtzq/i2c_mxs-timeout.patch
Full patch :
https://www.dropbox.com/s/0m9c6grkr4dp4j0/i2c_mxs-FULL.patch
Nicolas
Hi Nicholas,
I've gone to the stock Arch image, which performs i2c well enough that I can now spend my time on other things. Thanks for all your help.
-harold
Quote from: htarold on January 24, 2013, 03:04:02 AM
Hi Nicholas,
I've gone to the stock Arch image, which performs i2c well enough that I can now spend my time on other things. Thanks for all your help.
-harold
Specifically, which image is this?
I have been messing around with a bunch of options, ending with Linux 3.7.4, but the timeout problem persists. I'd like to compare a known, working kernel with the sources I'm using, see what's missing.
Also, as a general question, I'm finding that earlier versions of the kernel allow a Go executable to run, a newer version reports an illegal instruction (details unknown, the reported "core" file does not materialise). I presume I've left out some configuration detail, but there are so many, it would be hard for me to find the missing one. I have a feeling floating point stuff is missing, but I'm a bit of a newbie about all this.
Lucio.
Hi Lucio,
I'm currently using the ArchLinux image from :
http://archlinuxarm.org/platforms/armv5/olinuxino (http://archlinuxarm.org/platforms/armv5/olinuxino)
olinuxino kernel: [ 0.000000] Linux version 3.7.2-2-ARCH (nobody@panda2) (gcc version 4.7.2 (GCC) ) #1 PREEMPT Thu Jan 17 07:51:19 UTC 2013
olinuxino kernel: [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
olinuxino kernel: [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
olinuxino kernel: [ 0.000000] Machine: Freescale i.MX23 (Device Tree), model: i.MX23 Olinuxino Low Cost Board
Installed GCC+make then compiled "i2c-tool" , tested with a LM75 device (i2c address: 0x48):
[root@olinuxino i2c-tool]# ./i2c-tool -rw 0 0x48 2 1 0x00
Number of parameters: 7
SLAVE ADDRESS: 0x48
NUMBER OF BYTES TO READ: 2
NUMBER OF BYTES TO WRITE: 1
/dev/i2c-0 OPENDED!
MEMORY ALLOCATED AT ADDRESS: 0xA04008
MEMORY ALLOCATED AT ADDRESS: 0xA04018
PACKET DATA:
--------------------
ADDRESS: 0x48
FLAG: 0x00
LENGHT: 0x04
ADDRESS: 0x48
FLAG: 0x01
LENGHT: 0x04
MESSAGES: 2
SENDING:DONE
BYTE[0]: 0x12
BYTE[1]: 0x60
I've also been looking at this for awhile, 3 months now, if accessing a i2c address that is not mapped by a device on the bus, DMA does not terminate properly. In the 3.7, I just added a dmaengine_terminate_all(i2c->dmach); each time a i2c access is called. Thus clearing any DMA issues.
Quote from: tcmichals on January 29, 2013, 08:28:26 PM
I've also been looking at this for awhile, 3 months now, if accessing a i2c address that is not mapped by a device on the bus, DMA does not terminate properly. In the 3.7, I just added a dmaengine_terminate_all(i2c->dmach); each time a i2c access is called. Thus clearing any DMA issues.
Is that included in your old patch?
Yes, it is in one of my old patches. It was not accepted into the kernel.
Here is the modification to the code:
static int mxs_i2c_dma_setup_xfer(struct i2c_adapter *adap,
struct i2c_msg *msg, uint32_t flags)
{
struct dma_async_tx_descriptor *desc;
struct mxs_i2c_dev *i2c = i2c_get_adapdata(adap);
if (msg->flags & I2C_M_RD) {
i2c->dma_read = 1;
i2c->addr_data = (msg->addr << 1) | I2C_SMBUS_READ;
/*
* SELECT command.
*/
/* Queue the PIO register write transfer. */
i2c->pio_data[0] = MXS_CMD_I2C_SELECT;
desc = dmaengine_prep_slave_sg(i2c->dmach,
(struct scatterlist *)&i2c->pio_data[0],
1, DMA_TRANS_NONE, 0);
if (!desc) {
dev_err(i2c->dev,
"Failed to get PIO reg. write descriptor.\n");
goto select_init_pio_fail;
}
dmaengine_terminate_all(i2c->dmach); // <--- Add this to clear any old pending DMA..
/* Queue the DMA data transfer. */
sg_init_one(&i2c->sg_io[0], &i2c->addr_data, 1);
dma_map_sg(i2c->dev, &i2c->sg_io[0], 1, DMA_TO_DEVICE);
desc = dmaengine_prep_slave_sg(i2c->dmach, &i2c->sg_io[0], 1,
DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc) {
dev_err(i2c->dev,
"Failed to get DMA data write descriptor.\n");
goto select_init_dma_fail;
}
Quote from: Dataedge on January 29, 2013, 08:11:30 PM
Hi Lucio,
I'm currently using the ArchLinux image from :
http://archlinuxarm.org/platforms/armv5/olinuxino (http://archlinuxarm.org/platforms/armv5/olinuxino)
olinuxino kernel: [ 0.000000] Linux version 3.7.2-2-ARCH (nobody@panda2) (gcc version 4.7.2 (GCC) ) #1 PREEMPT Thu Jan 17 07:51:19 UTC 2013
olinuxino kernel: [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
olinuxino kernel: [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
olinuxino kernel: [ 0.000000] Machine: Freescale i.MX23 (Device Tree), model: i.MX23 Olinuxino Low Cost Board
I have the same kernel version (3.7.2-2-ARCH) running right now, but the output from running the recommended:
./i2c-tool -w 0 0x48 4 0x02 0xa0 0x40 0x03
still comes back with a time out error. I can't believe that the user level application can be responsible, so I'm beginning to suspect the MOD-IO2 device from Olimex.
In case somebody here wants to comment, the MOD-IO2 is pristine as received from Olimex, is powered with the specified 12V DC and connected with a short ribbon cable (15 cm, I believe - female plugs at each end). Nothing else is connected to it.
I will continue to experiment, there is much I need to learn about, but getting the MOD-IO2 to work as specified would be my first objective.
Thanks to all that have helped so far.
Lucio.
PS: I just have to fix the spelling errors in i2c-tool.c, they drive me insane, who do I submit the fixes to?
Patch tested on linux-next20130218.
https://www.dropbox.com/s/5t5ewcvtsuh4oba/next20130218_i2c-mxs.c.patch
On this next, I've an error when I read data with i2get. It always return i2c device address from MXS_I2C_DATA.
It seems the loop read too fast data after writing "read command" into MXS_I2C_CTRL0.
With a delay of 200us before read MXS_I2C_DATA, it works for me.
If anyone want try.
Hey Nicolas,
confirmed, your patch works in my system too! You can safely apply this from 3.8 next20130218 kernel onwards. Checked with my device tree files :
imx23.dtsi chunk:
...
i2c0: i2c@80058000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx23-i2c";
reg = <0x80058000 0x2000>;
interrupts = <27 26>;
clock-frequency = <100000>;
fsl,i2c-dma-channel = <3>;
status = "disabled";
};
...
imx23-olinuxino.dts chunk
...
i2c0: i2c@80058000 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
tsl2561: tsl2561@29 {
compatible = "taos,tsl2561";
reg = <0x29>;
};
lm75: lm75@48 {
compatible = "national,lm75";
reg = <0x48>;
};
};
...
The above because I've a LM75 temperature sensor (I2C addr.0x48) and a TSL2561 light sensor (I2C addr.0x29).
Enabled in kernel menuconfig under Device Drivers:
industrial I/O subsystem -> Light sensors -> TAOS TSL2560, TSL2561, TSL2562 and TSL2563 ambient light sensors
Hardware Monitoring support -> National Semiconductor LM75 and compatibles
Quote from: Fabio Estevam on November 08, 2012, 06:05:36 PM
LRADC is already supported in 3.7-rc4.
Actually, not. The driver is there but the devicetree setup is still
lacking in recent kernels.
The quick hack: just setting status from "disabled" to "okay" gives me
something. (Not yet tested with some real HW.)
A proper fix likely will need some pinctrl setup, but I don't understand
that well enough to do it myself.
Harald