RE: [Lcd4linux-devel] RE: [lcd4linux] problem with i2c connected LCD display

[Luis.F.Correia <Lui...@se...>]

Ok, i'll try to give as much info as I can... 

> -----Original Message-----
> From: paul kamphuis [mailto:pau...@xs...] 
> Sent: Friday, February 11, 2005 10:39 AM
> To: lcd...@li...
> Subject: Re: [Lcd4linux-devel] RE: [lcd4linux] problem with 
> i2c connected LCD display
> 
> Hi there,
> 
> Thanks for inviting me in! I already gave the 0.10 source 
> code a quick 
> look (just a download from the sources on the website, no CVS 
> access yet)
> Compiles nicely for me, so no problem there.
> 
> I agree with Luis his code, it looks nice and usable. But it doesn't 
> compile :'(
> I spend some time looking for a solution on the internet, and it is a 
> bit of a horror story.

Calm down :) it is now as bad as that...

> 
> First Luis, did you ever get this code working? Right now I assume it 
> could have worked with a 2.4.x kernel.

Yes, it was tested with 2.4.26, but I'm using a very non standard thing
that is, not using external I2C things, but the included linux i2c
'extensions'.

Then I used the i2c driver for the WRAP platform (which is what I was
working
on back then). (http://www.pcengines.ch/wrap.htm)

I did not use any kind of modules at all, I did plain old direct access
to the chip via the i2c_smbus commands.

> 
> The thing is, the kernel team decided that user space (application) 
> access to /dev/.. should not be done. For that reason most kernel 
> includes are no longer available. Only exception the i2c includes. 
> <linux/i2c.h> etc, but including them results in compile errors. (As 
> Michael noted)
> The reason is an undefined __user__  macro. Which  is part  of the 
> kernel teams effort to change the user space behaviour (if I 
> understand 
> correctly). Only found a single note on how to solve it; add #include 
> <linux/compiler.h>. And yes, it compiles nicely. Unfortunatly 
> it doesn't 
> link. The i2c_smbus functions are unresolved. So far I found 
> no solution 
> for this :'(

Yes, that was the issue I was trying to solve when I finally gave up.
We should not do direct kernel mode calls, but use the userspace layer
the i2c project provides. I could not make it work with my WRAP device.

> 
> So how does the kernel team wants us to access devices? If I 
> understand 
> it correctly it is supposed to go through dedicated kernel 
> modules like 
> pcf8574 (part of the 2.6 kernel) which are supposed to show up as 
> devices in /sys (sysfs). I am using the Gentoo 2.6.10-r6 kernel and a
> 
>   modprobe pcf8574

That combined with the correct bus driver for your hardware should make
it work OK.

> 
> results in a /sys/bus/i2c/devices/0-0020 device. This contains (among 
> some other files) a read and write file. Apperently writing 
> to the write 
> file should write data to the connected pcf8574. (I haven't 
> tested it yet)
> 
> So my question is. Would going for the /sys device be the 
> right solution 
> for lcd4linux?

Well, it 'may' work, but it is probably very slow to access. 

You should use the I2C API to access the device (if there is one)

> 
> Paul
> 

Luis Correia