How to port my device sensor [psensor] into Gingerbread

[jagan]

Hi All,

I am upgrading my android device[with qualcomm chipset] into
Gingerbread.

I am facing a problem with All my sensors are not working on device.

I ported:
-----------
=> sensor drivers in kernel [i got the boot up sensor init logs]
=> my HAL sensor daemon [having all sensor operations from user space
to call driver code]

With the above changes my sensors are not working.

As per my analysis there is a new sensorservice layer is added in
Gingerbread.

Is there any way to change my HAL, to support new sensorservice added
by GB.

Please tell me any one how to add my sensor HAL to Gingerbread.

Thank you.
Jagan

[Luo Chunbo]

There framework for sensors are changed in Gingerbread.

And and think you can refer device/htc/passion-common/libsensors
or device/samsung/crespo/libsensors

There are some sample code of sensors in these directories.

Thanks
Chunbo

[DanM]

Is your sensor library being loaded at boot?

Maybe put some log messages in your HAL and first verify that the
sensor library initialized.
Are you sure that the drivers are producing data?

Dan

[jagan]

I got the sensor boot logs for drivers,
but while testing any sensor i didn't get any logs from HAL.

Jagan

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

[DanM]

I assume you are checking the logcat log and not the kernel log?

If you are checking logcat and don't see that your HAL is started make
sure your sensor HAL .so has the correct name
or else Android will not find the HAL and load it

Dan

[Aditya]

Dan, 

 I had the exact same problem, and my HAL (Hardware Access Layer) was had a different name. Took me a while to figure it out. It would be a good idea to submit in the the exceptions for this.

-Aditya

--
Aditya Mukherjee
Rutgers University
Department Of Computer Science

[jagan]

Hi.

As the newly added sensor framework layer in GB.

we may need to change you HAL.

For reff. HAL see device/htc/passion-common/

libsensors

Jagan.

[jagan]

Hi.

With a reff. of device/htc/passion-common/
I am able to port p-sensor on my device.

I am testing with calling my device to another device, after receiving i put my device into my ear.
screen is OFF, while removing screen ON.. upto here ok.

when i do the same thing in multiple times, at one instance while i am putting my device into my ear,
it's going OFF, while removing it's screen is not turn back to ON.
but when i connect my usb cable, it's turn ON.

What is the relation between p-sensor vs USB here.?

I am changing my p-sensor driver that supports input subsystem by setting params as
input_set_abs_params(input_dev, ABS_DISTANCE, 0, 1, 0, 0);.

Is the above setting is correct for Proximity Sensor?

Please correct me if any thing i am setting wrong.

Please let me know if any inputs on this issue.?

Thanks,
Jagan

[DanM]

More then likely when you plugged in your USB cable it caused the
battery to start charging which will wake up the device.

If you report a binary from the prox sensor make sure the sensor HAL
converts this to millimeters.

Dan

> > On Mon, Apr 18, 2011 at 6:04 PM, Aditya <aditya.s.mukher...@gmail.com>wrote:
>
> >> Dan,
> >>  I had the exact same problem, and my HAL (Hardware Access Layer) was had
> >> a different name. Took me a while to figure it out. It would be a good idea
> >> to submit in the the exceptions for this.
> >> -Aditya
>

[jagan]

Hi Dan,

I didn't get you what you explain.

Could you please Elaborate.

Jagan.

[mike digioia]

I think he is saying to check to see that your JNI and app handle the binary type if you use Binary Attributes in the driver

[jagan]

Hi Dan.

For distance event point of view the below are observations

in my driver:
-----------------

              input_set_abs_params(input_dev, ABS_DISTANCE, 0, 1, 0, 0);.

in my HAL:
----------------
I am setting distance as follows

#define PROXIMTY_THRESHOLD                    9.0f

float indexValue (size_t index) {
       return index * PROXIMITY_THRESHOLD;
}

pending_event.distance = indexValue(event->value);

Is there any problem with index calculation in  indexValue()?  or
PROXIMTY_THRESHOLD value is improper?

Please let me tell me know if you have any inputs.

Jagan.

[jagan]

Hi Dan.

Could you please help if you have any inputs on this issue.

[DanM]

So you have a binary prox sensor that reports a zero or one to the
sensor HAL.
The sensor HAL should convert this to some distance in millimeters to
report this to the application layer.
This, in your case, will either be 0 or 9mm.

Do you know how far off the glass the proximity is supposed to
trigger?
Thats what PROXIMITY_THRESHOLD is supposed to be set to.

You also need to tell the Sensor Manager the proximity attributes via
the sensors_t struct.

Incorrectly defined attributes may mean that the value may not be
reported to the application.

Dan

On Apr 21, 9:45 am, jagan <402ja...@gmail.com> wrote:
> Hi Dan.
>
> Could you please help if you have any inputs on this issue.
>
>
>
>
>
>
>
> On Wed, Apr 20, 20input11 at 10:56 PM, jagan <402ja...@gmail.com> wrote:
> > Hi Dan.
>
> > For distance event point of view the below are observations
>
> > in my driver:
> > -----------------
>
> >               input_set_abs_params(input_dev, ABS_DISTANCE, 0, 1, 0, 0);.
>
> > in my HAL:
> > ----------------
> > I am setting distance as follows
>
> > #define PROXIMTY_THRESHOLD                    9.0f
>
> > float indexValue (size_t index) {
> >        return index * PROXIMITY_THRESHOLD;
> > }
>
> > pending_event.distance = indexValue(event->value);
>
> > Is there any problem with index calculation in  indexValue()?  or
> > PROXIMTY_THRESHOLD value is improper?
>
> > Please let me tell me know if you have any inputs.
>
> > Jagan.
>
> > On Wed, Apr 20, 2011 at 9:24 PM, mike digioia <mpd...@gmail.com> wrote:
>
> >> I think he is saying to check to see that your JNI and app handle the
> >> binary type if you use Binary Attributes in the driver
>

> >> On Wed, Apr 20, 2011 at 8:50 AM, jagan <402ja...@gmail.com> wrote:
>
> >>> Hi Dan,
>
> >>> I didn't get you what you explain.
>
> >>> Could you please Elaborate.
>
> >>> Jagan.
>

[jagan]

Hi Dan,

Thanks for your response.

Please identify the Sensor Attributes like

                name: "my_prox",
                vendor: "my_prox_ven",
                version: 1,
                handle: SENSOR_PROXIMITY_HANDLE,
                type: SENSOR_TYPE_PROXIMITY,
                maxRange: 9.0f,
                resolution: 9.0f,
                power: 0.5f,
                minDelay: 20000,
 
and my PROXIMTY_THRESHOLD would be 9.0f


Please verify the above attributes, tell me if anyting i did incorrect.

Thanks,
Jagan

[JakeLian]

Sorry, I have another question about driver implementation for
sensors.

The above discussion are all base on "input dev" mechanism, right?

If I implement a driver and base on "sysfs" mechanism (include get
sensor output value and set output data rate for sensor), how can I
report the sensor output value from HAL to framework?

[DanM]

Jagan
LGTM

Dan

[DanM]

Jake
Actually the readEvents implementation is all what you want it to be.

Currently Android uses the input_dev facilities to report sensor data.

But that is frowned upon by the input maintainer in the OS community.
They are looking at
using IIO kernel framework to report industrial sensor technology.

So to answer your question you can implement your read on your sysfs
entry or
your input device node. Retrieving the data from the driver really is
segregated from the actual
reporting of the data to the FW.

Dan

[JakeLian]

Dear Dan,

Thanks for your suggestions and responses.

Regarding to my question, I have the solution and implement done.

My solution is writting a function to get sensor output data from
sysfs and report it to the framework, then we can monitor it via some
sensor related apk.

Best Regards
Jake

[jagan]

Dan,

Then what is significance of maxRange, resolution w.r.t PROXIMITY_THRESHOLD value.

When i update the above attributes also,
Some times my device is not resumes, while it is away from my ear.

Thanks,
Jagan

[DanM]

Are you sure that the proximity sensor sent the data to the user space
to wake up the device?
Are you sure that the proximity driver is configured as a wakeable
interrupt?

Dan

[jagan]

Hi Dan,

I still unable to resolve my p-sensor issue.

I will tell you the issue once again
=> Receive one MT call
=> Answer the call and put device to close to your ear
=> P-sensor can work and backlight turn off
=> while i am moving phone away from EAR screen is not turned ON.

My p-sensor h/w is capella, due to this reason
=> i took the p-sensor HAL from device/htc/passion-common/

libsensors  /ProximitySensor.cpp
=> I registered my driver with input core [earlier in froyo my driver doesn't have input core]

P-sensor is working with USB cable, but w/o USB cable screen is not turned ON when i move the device away from my EAR.

I attach a HAL code, logs for working & non working case.

How to configure my prox driver as support wakeable
interrupt?

Please let me know if you have any inputs on this.
let me know if you have any concerns.

Regards,
Jagan.

[jagan]

Hi Dan,

I confirm that my driver is configured as wakeble interrupts support.

Regards,
Jagan

[Chinmay S]

Hi Jagan,

From the attached logs, its obvious that in the non-working case (w/o the USB cable),
the device has entered complete suspend ( Userspace processes frozen )
and hence the Sensor-HAL code wont be active.

From the logs you have shared, it appears that the device after going into suspend,
never wakes-up. ( even after the external IRQ on the proximity sensor line)

Ideally, if the device is suspended,
the proximity-sensor IRQ should wake-up the device & psensor_irqhandler should be called.
the HAL will come into the picture ONLY after that.

Do verify that the proximity sensor IRQ line is in fact waking-up the device.
i.e. the following log should be present in the wake-up path when you move your ear away.

psensor_irqhandler: Starts ##########

Can you please confirm that the device is indeed waking up?

regards
CVS

[jagan]

Hi CVS,

Thanks for your response.

For non working case [w/o USB] the device is completely suspend.

I should wake-up in two situations
1. Connect USB, move the device near to EAR it's wake-up...and continue again
2. When call is disconnected by another end. device comes with home-screen.

In non-working case i didn't get any IRQ from p-sensor.

Please let me know if u have any concerns.

Regards,
Jagan.

--

[Chinmay S]

Hi Jagan,

So, its confirmed that the psensor IRQ has NOT triggered in the non-working case,
it looks like the psensor IRQ line did not wake-up the suspended device.

Which SoC are you using in your device?
Is "wakeup-support" available on the psensor IRQ line?
How did you enable it?

regards
CVS

[jagan]

Hi CVS,

My device runs on qualcomm Snapdragon.
Yes my device having a support for wakeup-support, i enabled & disabled
during ENABLE & DISABLE ioctls from HAL with enable_irq_wake() & disable_irq_wake()
calls.

Regards,
Jagan.

regards
CVS

--

[jagan]

Hi,

Final my p-sensor is working fine.

The fix areas are: p-sensor disable ioctl() & platform gpio configurations.

Because of improper configuration in GPIO, while I am moving my device away
from EAR, proximity h/w able to generate interrupt but my driver is unable to proceed.

Thanks for Android google groups & CVS for quick response.

Regards,
Jagan