Can't receive RX_FULL interrupt when communicate with sensor hub

Follow this topic:

http://www.osronline.com/showthread.cfm?link=258269

I have implemented an i2c controller driver for Haswell which based on Designware driver (linux).

http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-designware-core.c

It work quite well, now can get the descriptors + reports for touch panel. But when I install it on sensor hub, I can’t get any RX_FULL interrupts.

May be it is related to power policy? In ACPI table I see that the different between touch panel and sensor hub is the touch panel has:

Name (_S0W, 0x04) // _S0W: S0 Device Wake State

While sensor hub doesn’t.

Both of them are i2c-hid devices so I think they are pretty same.

xxxxx@gmail.com wrote:

Follow this topic:

http://www.osronline.com/showthread.cfm?link=258269

I have implemented an i2c controller driver for Haswell which based on Designware driver (linux).

http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-designware-core.c

It work quite well, now can get the descriptors + reports for touch panel. But when I install it on sensor hub, I can’t get any RX_FULL interrupts.

May be it is related to power policy?

How could that POSSIBLY be the case? Power policy is about negotiating
in software. You’re talking about a HARDWARE interrupt. Are you
getting any interrupts at all? Have you used a scope to verify that
data is actually being returned?

Either you aren’t enabling the interrupt, or the devices aren’t sending
anything, or the interrupt is coming in and you are accidentally losing it.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Sorry, I make it confusing.

Actually I can receive the interrupt, but the flag RX_FULL(indicate the meaning of interrupt) has never set. TX_EMPTY can be received as normal so previously I think the device is not responding by some reasons.

I’m sure that I have sent “right things” to device because it work well with touch panel, another i2c-hid device. This is just a standard request to get hid descriptor.

But sensor hub doesn’t respond.

Are you sure the sensor hub is powered up? Perhaps it’s time to hook up a probe and check whether the traffic you’re sending on the bus is correct?

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, July 31, 2014 10:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can’t receive RX_FULL interrupt when communicate with sensor hub

I’m sure that I have sent “right things” to device because it work well with touch panel, another i2c-hid device. This is just a standard request to get hid descriptor.

But sensor hub doesn’t respond.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thanks,

Seeams like my sensor isn’t powered. In the documentation, “power well” of sensor hub is “suspend” rather than “core”. I don’t get these terms but it look like make sense. An electrical guy also told me that the way of powering for sensor hub and touch panel are different(he only lookat the schematics diagram). I’m waiting for confimation from the hardware vendor.

But I still looking at how to powerup this “suspend power well”, sensor hub still work with the stock driver in Win8 so I think it should be an software task.

I still stucked,

By evaluating an ACPI method(PowerResource._STA), I found that the value of GPIO46(Sensor Hub Power Enable) is “1”. Seems like the sensor hub has been powered up.

But it isn’t responding.

Put a logic probe or a volt meter on Vcc of the device. Then tell us if the device is powered up.

Peter
OSR
@OSRDrivers

– Put a logic probe or a volt meter on Vcc of the device. Then tell us if the
device is powered up.

Yes, but my hardware team got some difficult to do it :frowning: Still trying…

The behavior of the I2C0 controller(sensor hub) and I2C1 controller(touch panel) are also different. When I write to I2C0, I always have ACKs, even with a bad slave address. This case in I2C1 will result as an abort. Pretty strange behavior, I can’t explain it.

Everything still work well with the inbox driver in Win8 so evidently this is a driver problem.

Could someone give me any ideal about what happen?