kernel 2.6.32

January 8, 2012

i dont have much to say just that u are great :)

keep up good work

January 8, 2012

My compilation of what kernel probes according to dmesg I was able to find on Internet and which cameras are supported by proprietary libqcamera.so

I didn't find our cameras on other boards, but support for them are definitely in msm7225 .32 devices:

- kernel probes them,

- libqcamera.so have them

EDIT: also added Gingerbread device based on msm7227

Edited January 8, 2012 by pier11

January 8, 2012

On the other note, that libcamera source from motorola cliq xt, gibgerbread, - it might be what is needed to glue .29 infrastructure to cm7 (gingerbread). Try to compile it with cm7 :-)

I will give it a try soon. But I noticed that its msm_camera.h does not match well with pulse .29;

The closes match to pulse .29 is in geeksphone/one. I compiled that libcamera, but it crashes when trying to load pulse libmmcamera.

I would like to combine it with geeksphones libmmcamera (and .29 kernel). The problem is that geeksphones libs expect the camera to be at "/dev/msm_camera".

So my idea would be to modify .29 kernel to create /dev/msm_camera instead of /dev/msm_camera/msm_camera0

I have several experiments in mind:

1) geeksphones libcamera built from source + pulse libs + .29 kernel unmodified

--> doesn't work (crashes before loading)

--> from several previous experiements I got the impression that Pulse's libs seem to crash on gingerbread in every combination. I guess they are simply too old (most likely cupcake ones that were made to work on eclair somehow)

2) geeksphones libcamera built from source + geeksphones libs + .29 kernel unmodified

--> no crash, but camera not opened because expected to be at /dev/msm_camera, can be seen on logcat

--> TODO experiment 3

3) like 2 but with .29 kernel modified to map camera0 to /dev/msm_camera

--> to be done

5) motorola libcamera built from source + motorola libs + .29 kernel recompiled with msm_camera.h from motorola

--> interesting because moto libs want /dev/msm_camera/msm_camera0, and this is what we have, but kernel needs to be recompiled because of the changed API (esp. ordering of elements in msm_ctrl_cmd)

--> to be done

and, perhaps most interesting

6) try building several libcameras from source that have msm_camera.h like in .32 kernel + u8150 libs + .32 kernel

--> if we find one that reproduces the current "freezing preview", we have better chances to debug this when we can modify libcamera source

--> to be done

I don't know anything about kernels. Do you happen to know where I have to look to change where the devices get mounted? Experiment 3 might be interesting...

Edited January 8, 2012 by dr.flo

January 8, 2012

I don't know anything about kernels. Do you happen to know where I have to look to change where the devices get mounted? Experiment 3 might be interesting...

/dev/msm_camera/* are instantiated by msm_camera.c (link to our .29 kernel)

int msm_camera_drv_start():

msm_class = class_create(THIS_MODULE, "msm_camera");  <-- this is /dev/msm_camera node


static long msm_setup_cdevs():

sprintf(name, "%s%d", "msm_camera", MINOR(devno));

class_dev = device_create(msm_class, NULL, devno, "%s", name);  <-- this creates /dev/msm_camera/msm_camera0

As far as I understand.

January 8, 2012

Works on stock Froyo rom from u8150:
- display
- touchscreen
- keypad
- jogball
- usb: mass storage, adb
- sd card
- backlight/brightness
- vibrator
- sensors
- very partially camera

Doesn't work:
- radio
- mobile data network
- wifi
- bluetooth
- sound/mic
- keypad LEDs
?- hardware acceleration

Actually stock wifi driver loads fine with insmod if do it manually. It could be something with permissions.

With regard to camera I'm also getting simi-positive results. If on CM6 camera did't even try to start, on froyo stock rom I'm getting:
- preview with very weird inverted colors;
- preview freezes soon after. So I can't take a picture.

Sensors (rotation) actually work too, if not try to adopt .32 kernel for our modified for .29 CMs, but leave it as it is. (I didn't commit that mods to git, and was right...)

January 8, 2012

Sensors (rotation) actually work too, if not try to adopt .32 kernel for our modified for .29 CMs, but leave it as it is. (I didn't commit that mods to git, and was right...)

I think it is best to keep your .32 kernel as stock'ish as possible. Only those components should be modified where the pulse's hardware requires it.

For CM7, there should be enough sources for native .32 devices available. There is a device "u8150" folder in the repo. This would build CM7 for stock u8150. Whenever s.th. works on your stock froyo rom + your kernel, we will be able to make it work in CM7 also.

Having said that, I've given up on camera experiments with the .29 kernel; Will focus now on what I called "experiment 6" above.

January 8, 2012

Great work guys. I'm the dev for cm7 on the u8150 so if you need any info ill be glad to help!

January 8, 2012

Great work guys. I'm the dev for cm7 on the u8150 so if you need any info ill be glad to help!

Thanks, tilal6991, for visiting us and offering your help!

We are trying to catch up with progress with our u8220/u8230 phones. Unfortunately Huawei left us with Eclair and 2.6.29 kernel.

Long time ago already people - TomG and others - ported CM7, but using 2.6.29 kernel. Camera still an issue since.

This days we are trying (and succeed to degree) to build newer kernel - 2.6.32 - and rebase roms to it.

Our kernel 2.6.32 is based on u8150 Huawei's source (see git). We also use stock u8150 rom as a reference for froyo...

One of main goals for us is to make cameras work on CM7.

Only success we experienced on CM6 with older camera libs from our Eclair. But had basically nothing on CM7 with regards to cameras.

With combo of 2.6.32 kernel + stock u8150 froyo rom, we are getting preview, but with very distorted colors, and it freezes soon after.

May be you might have some ideas on where better to look?... Thanks.

January 8, 2012

Thanks, tilal6991, for visiting us and offering your help!

To tilal6991: Also a big thanks from my side. I think pier11 already described our current situation very well.... If you have any thoughts on this, please share them.

@pier11 - I just noticed that adb doesn't work when using your kernel and CM7 (don't matter if 7.1 or 7.2, and don't matter if building from the repo or using the 0.1 image you uploaded here). You said it works on froyo for you? Is this some CM hack to fit .29 kernel?

January 8, 2012

The camera libs relevant for the U8150 are:

libcamera.so

libmmprocess.so

libmmjpeg.so

libmmipl.so

sensors.*.so

January 8, 2012

@pier11 - I just noticed that adb doesn't work when using your kernel and CM7 (don't matter if 7.1 or 7.2, and don't matter if building from the repo or using the 0.1 image you uploaded here). You said it works on froyo for you? Is this some CM hack to fit .29 kernel?

Has adb ever worked for you with .32 kernel?

It always worked for me since early days with CM7, CM6, stock Eclair and stock Froyo.

What host is yours? Windows? I use Ubuntu. New usb identity required me (I think) to add 05c6:9018 (see below) to some configs to allow non-root access...

Only thing I can think of is that .32 uses Qualcomm idendity (a generic one) for usb, while .29 used Huawei's. That might cause some (windows?) drivers not recognize it...

$ lsusb

...

Bus 001 Device 127: ID 05c6:9018 Qualcomm, Inc.

January 9, 2012

The camera libs relevant for the U8150 are:
libcamera.so
libmmprocess.so
libmmjpeg.so
libmmipl.so
sensors.*.so

a logcat of a camera session on u8150 (either cm7 or froyo) might be interesting. maybe just open camera app, watch preview a few seconds, then close app without taking any picture.

Would be interesting to see if there is any difference in the cam startup compared to when the whole thing runs on pulse

January 9, 2012

Has adb ever worked for you with .32 kernel?
..
$ lsusb

...

Bus 001 Device 127: ID 05c6:9018 Qualcomm, Inc.

No - but I solved it. I was using an adb binary I found somewhere on the net. It was simply too old. I downloaded a new one, now it works. Seems that the adb binary has supported device IDs hardcoded...

January 9, 2012

Nice!

I'm looking at camera sensor driver code - ov3647.c. It looks to me command communication with camera goes via I2C interface:

search for ov3647_i2c_write gives 30 hits:

	Line 305: static int ov3647_i2c_write(unsigned short saddr,

	Line 323: 		CDBG("ov3647_i2c_write faild\n");

	Line 331: static int32_t ov3647_i2c_write_table(struct ov3647_i2c_reg_conf *reg_conf_tbl, int num_of_items_in_table)

	Line 338: 		rc = ov3647_i2c_write(ov3647_client->addr,

	Line 368: 	rc = ov3647_i2c_write(OV3647_AF_I2C_ADDR >> 1,

	Line 495: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x2, aec_msb);

	Line 499: 		rc = ov3647_i2c_write(ov3647_client->addr, 0x3, aec_lsb);

	Line 510: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x2d, aec_msb);

	Line 514: 		rc = ov3647_i2c_write(ov3647_client->addr, 0x2e, aec_lsb);

	Line 522: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x1, gain);

	Line 554: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x2, aec_msb);

	Line 558: 		rc = ov3647_i2c_write(ov3647_client->addr, 0x3, aec_lsb);

	Line 569: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x2d, aec_msb);

	Line 573: 		rc = ov3647_i2c_write(ov3647_client->addr, 0x2e, aec_lsb);

	Line 581: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x1, gain);

	Line 603: 				rc = ov3647_i2c_write_table(ov3647_preview_reg_config,

	Line 608: 				rc = ov3647_i2c_write_table(ov3647_snapshot_reg_config,

	Line 615: 			rc = ov3647_i2c_write_table(ov3647_init_reg_config,

	Line 627: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x24, ov3647_reg_pat[rt].x_output_size>>4);

	Line 630: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x25, ov3647_reg_pat[rt].x_output_size<<4);

	Line 634: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x26, ov3647_reg_pat[rt].y_output_size>>4);

	Line 637: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x27, ov3647_reg_pat[rt].y_output_size<<4);

	Line 641: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x28, ov3647_reg_pat[rt].line_length_pck>>8);

	Line 644: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x29, ov3647_reg_pat[rt].line_length_pck);

	Line 648: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x2a, ov3647_reg_pat[rt].frame_length_lines>>8);

	Line 651: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x2b, ov3647_reg_pat[rt].frame_length_lines);

	Line 655: 	rc = ov3647_i2c_write(ov3647_client->addr, 0x12, rt == RES_PREVIEW ? 0x10 : 00);

	Line 791: 	if (ov3647_i2c_write(OV3647_AF_I2C_ADDR >> 1,

	Line 794: 		CDBG("ov3647_i2c_write is failed in ov3647_move_focus\n");

	Line 886: 	rc = ov3647_i2c_write(ov3647_client->addr,

I also configured our cameras in I2C init data on our board board-u8220.c

That makes me think that msm_camera.h data structures are irrelevant to communication to camera hardware (they are not passed as is, but data is taken from them when needed). That interface is for communication via ioctl between user space - libcamera.so and kernel - msm_camera.c. So if libcamera.so understands kernel, that's enough. Changes in that interface won't affect communication with camera hardware.

2. There are many debug entries in file - ov3647.c. They would be enabled - and logs captured - both on .29 kernel and .32 kernel. The driver - ov3647.c - is nearly identical in both kernels... May be same for mt9t013_byd.c

EDIT:

2a. Even better to monitor i2c communication by logging before i2c_transfer() . Applicable to both our sensors.

Edited January 9, 2012 by pier11

January 9, 2012

another thought is if we use different cameras, but they behave in the same fashion, than the issue is not with drivers, but in parts, that are common to us. These either above sensors:

- msm_camera.c

- libcamera.so

or "aside":

- dsp (seem cameras use it. Code is in arch/arm/mach-msm/qdsp5 This time Huawei used own version again: qdsp5_7200A );

- v4l...

January 9, 2012

This Android 2.2 iPhone 4 clone is called W801 and it is equipped with Qualcomm MSM7200A 528MHz CPU plus a 3.5 inch HVGA capacitive multi touch-screen, 512/288 memory, 4G flash memory, GSM&WCDMA network supporting, G-sensor, GPS, WIFI and a 3.2 megapixel camera(without flash light).

drivers mentioned above, telephone will help?

Edited January 9, 2012 by romea

January 9, 2012

drivers mentioned above, telephone will help?

Just wondering, I hope I'm not insulting you, but do you have problems with your eyesight? :/

January 10, 2012

2.6.32 stock froyo rom:

Here is what dmesg says if turn on logging in camera sensor - ov3647.c

A variant with logging of ov3647_i2c_write() method.

Capture from stock camera start till freeze

--------------------

2.6.29 official kernel, CM6.1 (camera works)

Log of the same to compare.

Log with writing debug of ov3647_i2c_write() method.

Edited January 10, 2012 by pier11

January 10, 2012

Did you ever try out the patched CM7 I uploaded? Just to see if the camera behaviour there is really the same as in u8150 froyo?

Tried your CM7 with updated cam libs. Behavior is exactly the same as in u8150 froyo.

The only difference maybe is that I don't always need to restart phone to restore cam.

January 10, 2012

another thought is if we use different cameras, but they behave in the same fashion, than the issue is not with drivers, but in parts, that are common to us. These either above sensors:
- msm_camera.c
- libcamera.so
or "aside":
- dsp (seem cameras use it. Code is in arch/arm/mach-msm/qdsp5 This time Huawei used own version again: qdsp5_7200A );
- v4l...

This might be true... after all it's very unlikely that the same bugs would be present in the drivers of both camera sensors.

Also, on sunday I did a quick hack: Using AntonioPT's .29 kernel, I simply reverted msm_camera.h and the contents of the 7x0x folder to their .29 normal versions. I ended up with /dev/msm_camera/control0 etc devices being created by .29 kernel. Therefore I expected to get the same behaviour of the camera app, but it didn't open at all.

This also indicates that not only the camera drivers part of the kernel influences what we see...

Do you know about other apps the require a fully functional qdsp5? Maybe mediaplayers and such? I think we didn't test yet whether any other application that relies on the dsp would also freeze after a few seconds...

Another thing: I've seen that you already ported the ascend(m860) eclair kernel .29 to the pulse before. And you stated that the pulse's camera worked on stock pulse eclair. I guess this was because you ported the 7x0x hack to ascends kernel, right?

Any chance that the stock ascend eclair rom would boot with this kernel?

It would be interesting if ascend-eclair-29 on pulse + ascend-eclair-stock-rom gives the same freezing camera as u8150-froyo-32 on pulse + u8150-froyo-stock-rom

(of course then without porting 7x0x to ascends kernel)

Tried your CM7 with updated cam libs. Behavior is exactly the same as in u8150 froyo.

The only difference maybe is that I don't always need to restart phone to restore cam.

The restart issue is because I used libqcamera.so and so on from ascend; If you copy the versions from u8150 instead, less restarts are required.

(libqcamera.so of ascend and u8150 are different, but both connect to the same libcamera.so)

January 10, 2012

Another thing: I've seen that you already ported the ascend(m860) eclair kernel .29 to the pulse before. And you stated that the pulse's camera worked on stock pulse eclair. I guess this was because you ported the 7x0x hack to ascends kernel, right?
Any chance that the stock ascend eclair rom would boot with this kernel?

Don't pay much attention to that experiment, I transfered very big chunks of pulse kernel into it. So essentially at became Pulse kernel. Pieces were:

- all architecture specific stuff, board included (arch/arm/mach-msm/*), qdsp5_7200A included;

- complete display driver (drivers/video/msm/*);

- complete camera driver (drivers/media/video/msm/*), 7x0x folder included (and of course compiled with it).

So no wonder it worked fine with .29 libs after that.

qdsp is mostly used by audio/mic as I understand. Sound worked with CM6/7, but not on stock froyo rom. On froyo rom instead of sound I hear just noise (but duration of the noise is correct. For example if I increase volume by pressing VolumeUp button, it making noise for a fraction of sec).

I think we need to test any video playback to see if it exhibit the same behavior - wrong colors, freezes.

I like your experiment with AntonioPT's kernel. That's how ascend .29 (or pulse-mini) was compiled. You probably needed stock qdsp5 instead of qdsp5_7200A, to make a match.

January 10, 2012

Another experiment is to record video from camera on working environments. Then playback it on .32 based systems.

That would prove that video playback route is fine - decoding/framebuffer/colors. So something before that is not right - v4l from camera?..

January 10, 2012

need to try to use msm_vfe7x (Video Front End) from .29 7x0x directory... Just to see if it makes any difference.

It's slightly different...

January 10, 2012

I like your experiment with AntonioPT's kernel. That's how ascend .29 (or pulse-mini) was compiled. You probably needed stock qdsp5 instead of qdsp5_7200A, to make a match.

Result: Doesn't crash anymore; instead says it cannot connect to camera. No preview, nothing.. ???

Another experiment is to record video from camera on working environments. Then playback it on .32 based systems.

Result: Playback of Video (recorded with eclair 2.1) works without issues in CM7 + kernel .32

Maybe you want to try that:

need to try to use msm_vfe7x (Video Front End) from .29 7x0x directory... Just to see if it makes any difference.
It's slightly different...

Tried this myself but gave up. msm_vfe7x from .29 kernel depends on msm_camera.h and camera.h in 7201A_SURF configuration, otherwise enums unknown, structs have different elements and so on. vfe is closely mixed with msm_camera stuff

To summarize: Unmodified .32 kernel with unmodified u8150 camera libs (which gives the freezing preview) still is the best of all combinations tried so far...

Edited January 10, 2012 by dr.flo

January 10, 2012

CONFIG_MSM_CAMERA_DEBUG kernel config option (in .config) should enable logging of all camera components (it un-void CDBG() function):

msm_camera.c
msm_vfe7x.c
flash.c
msm_v4l2.c
msm_axi_qos.c
ov7690.c
ov3647.c
mt9t013_byd.c

#ifdef CONFIG_MSM_CAMERA_DEBUG

#define CDBG(fmt, args...) printk(KERN_INFO "msm_camera: " fmt, ##args)

#else

#define CDBG(fmt, args...) do { } while (0)

#endif

This is for ultimate logs comparison between working .29 system and .32

kernel 2.6.32

Recommended Posts

Guest jeddy1

Link to comment

Share on other sites

Popular Days

Popular Days

Popular Posts

Guest pier11

Guest pier11

Guest pier11

Posted Images

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest tilal6991

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest tilal6991

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest romea

Link to comment

Share on other sites

Guest D-D-

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment