IIC troubles w/ ppc4xx (STB04)

IIC troubles w/ ppc4xx (STB04)

[Andre Draszik]

Hi,

I am having trouble using iic_smbus_quick() of i2c/busses/i2c-ibm-iic.c
I am trying to i2c_probe() to probe for some devices, which at the end
calls iic_smbus_quick().

Basically, I get a Data Machine Check as soon as iic->directcntl is
accessed. Actually, this register is not described in the (old)
documentation I have.
Is anybody using this successfully on STB04?


Greets,
Andre'

Re: IIC troubles w/ ppc4xx (STB04)

[Eugene Surovegin]

On Sun, Apr 16, 2006 at 03:41:28AM +0200, Andre Draszik wrote:
> Hi,
> 
> I am having trouble using iic_smbus_quick() of i2c/busses/i2c-ibm-iic.c
> I am trying to i2c_probe() to probe for some devices, which at the end
> calls iic_smbus_quick().
> 
> Basically, I get a Data Machine Check as soon as iic->directcntl is
> accessed. Actually, this register is not described in the (old)
> documentation I have.

Does everything else work? I mean ordinary I2C access like read/write.
If everything else is fine, just comment out that iic_smbus_quick() 
call or just don't use i2c_probe(). It's a hack anyway, because I2C 
spec has no provision for "probing". I wrote this bit-banging 
implementation just to get some people off my back :).

BTW, I never tested my driver on STB4, maybe ocp_defs are wrong (in 
this case i2c will not work at all).

-- 
Eugene

Re: IIC troubles w/ ppc4xx (STB04)

[Andre Draszik]

Hi,

Eugene Surovegin wrote:
> On Sun, Apr 16, 2006 at 03:41:28AM +0200, Andre Draszik wrote:
>> [...]
>> Basically, I get a Data Machine Check as soon as iic->directcntl is
>> accessed. Actually, this register is not described in the (old)
>> documentation I have.
> 
> Does everything else work? I mean ordinary I2C access like read/write.

Well, i2c-dev is working fine, so i2c in general is working (w/
2.6.17-rc1). And also the initialization of the ibm i2c driver works
fine, i.e. all other registers can be accessed. It's only the directcntl
which throws the exception.

> If everything else is fine, just comment out that iic_smbus_quick() 
> call or just don't use i2c_probe(). It's a hack anyway, because I2C 
> spec has no provision for "probing". I wrote this bit-banging 
> implementation just to get some people off my back :).

I see :) So if that doesn't work, what is the preferred way of testing
for existence of a device in a kernel module? Should I just
unconditionally i2c_client_register() a static struct and then
i2c_master_send() to see if it works?

> BTW, I never tested my driver on STB4, maybe ocp_defs are wrong (in 
> this case i2c will not work at all).

Nope, this is correct, I already checked. :)


Thanks!
Andre'

Re: IIC troubles w/ ppc4xx (STB04)

[Eugene Surovegin]

On Sun, Apr 16, 2006 at 07:33:45AM +0200, Andre Draszik wrote:
> I see :) So if that doesn't work, what is the preferred way of testing
> for existence of a device in a kernel module? Should I just
> unconditionally i2c_client_register() a static struct and then
> i2c_master_send() to see if it works?

There is no generic reliable way to detect that some i2c device exists 
on the bus. Even if smbus_quick worked it cannot guarantee that 
device you found is actually device you are expected - same i2c 
address can be used by different devices.

Frankly, I never saw this as a problem in embedded world, because 
most of the time you have a custom built kernel for your particular 
board or family of the boards, and you already know what devices might 
be there, so just trying to access those devices from whatever 
drivers and/or user-space applications you wrote is sufficient. In 
fact, I never needed i2c "probing" in any of almost dozen different 
embedded projects I wrote firmware/Linux board support for.

So, I think unconditional i2c_master_send() should be fine, just be 
prepared to handle errors in case device isn't there or broken.

-- 
Eugene

Re: IIC troubles w/ ppc4xx (STB04)

[Andre Draszik]

Eugene Surovegin wrote:
> On Sun, Apr 16, 2006 at 07:33:45AM +0200, Andre Draszik wrote:
>> I see :) So if that doesn't work, what is the preferred way of testing
>> for existence of a device in a kernel module? Should I just
>> unconditionally i2c_client_register() a static struct and then
>> i2c_master_send() to see if it works?
> 
> There is no generic reliable way to detect that some i2c device exists 
> on the bus. Even if smbus_quick worked it cannot guarantee that 
> device you found is actually device you are expected - same i2c 
> address can be used by different devices.

I know, I really meant the linux side of this, i.e. if there was maybe
something I missed till now. But doesn't seem so ;)

> Frankly, I never saw this as a problem in embedded world, because 
> most of the time you have a custom built kernel for your particular 
> board or family of the boards, and you already know what devices might 
> be there, so just trying to access those devices from whatever 
> drivers and/or user-space applications you wrote is sufficient. In 
> fact, I never needed i2c "probing" in any of almost dozen different 
> embedded projects I wrote firmware/Linux board support for.

Sure, normally you know which devices are there. I am just playing
around with two boards I have here and am adding/removing parts as I
like ;) Therefore, for the moment, I wanted my driver to be as flexible
as possible, so I thought i'd use some probing and do it the preferred
way w/o hardcoding anything. At least that's what I thought the
preferred way to be...


Thanks!
Andre'