[Huawei Ideos X5 U8800] Blefish:
When I rebased the work there was a commit not added on jb_2.5 that enabled a timeout when vsync is not coming. I have that fixed, but since NT35582 seems to not have any problems anymore with turning on, I will split the NT35582 driver and disable some of the commands sent to panel, it could solve the problem.

I doubt it's button backlight, but is it hot in the back side of the phone?

Do they turn on? Did you have this problem in the previous release?

Wi-Fi seems to work perfectly for me, no problems with bluetooth either. I even had bluetooth sending file & wifi downloading at the same time, without a problem.

What would happen if you'd decrease the gain? I posted a tutorial on how to do that few posts earlier. I did not notice much static in my speaker. Wi-Fi range may be related with qcom_cfg.ini . It's using the one from Aurora right now, so theoretically it should be same, nothing else can change it really :/.

The old method does not work right now, and /sdcard/ does not exist. This may explain why it would not show up over MTP. But bluetooth is something I don't quite get. Can you send files?

I don't think we have to report crashes in particular. They are mostly related with display/wi-fi.

The errors are normal, it's a problem with the recovery, and it does not change the behavior. However, moving one by one is a different problem. It could be related with NT35510 vsync issues. I am working on it right now.

Thanks for such a great report.

By crashing, gallery crashes? It's a rough indication that memory available is too low, there are some commits in code review that should improve the memory footprint for 512MB devices, so I could merge them in.

I believe the problem for vSync has been found. While I was trying to improve FPS, I disabled MDP internal vSync. That improved DMAP time (display buffer to panel buffer), however the same code was in the 3.0 codebase, and it was used to avoid tearing effects. So I am pretty sure this is the case here.

That brings the problem that FPS is now mostly 23 with MDP vSync enabled. So, DMAP is waiting on something before it actually updates the frame, making the DMAP time exactly 43msecs. That's capping the frame rate, and with MDP vSync disabled it did it in about 30msecs, clearly showing the FPS.

Right now, I am browsing around and checking on the configuration parameters again, trying to find the problem. The MDP vSync gives very little information about the parameters, and I have to manually modify something, reboot, seek for changes and so on.

Here's the function enabling it btw.

rdptr - the read pointer, triggers the vSync.

write ptr - write pointer, could be the point where dmap complete is sent.

Currently, panel parameters that are set:

v_pulse_width = 0;

v_back_porch = 6; // Set as MDDI panel register VPA has set it, total porch lines.

v_front_porch = 0;

Others are 0. Maybe someone has a solution, because I don't have a clue what the vsync_threshold_start & vsync_threshold_continue are doing or what are they taking as a parameter (time/lines/clock). The primary_vsync_init & primary_rdptr_irq are not clear too.

The part where it says adjust start position should be the problematic part, as currently it goes like: RDPTR, RDPTR, WRPTR, RDPTR, RDPTR, WRPTR. Having 21ms (vsync), 42ms (vsync), 43ms (dmap)

void mdp4_mddi_vsync_enable(struct msm_fb_data_type *mfd,
struct mdp4_overlay_pipe *pipe, int which)
{
uint32 data, tear_en;

tear_en = (1 << which);

mdp_clk_ctrl(1);

data = inpdw(MDP_BASE + 0x20c);
if ((mfd->use_mdp_vsync) && (mfd->ibuf.vsync_enable) &&
(mfd->panel_info.lcd.vsync_enable)) {
data |= tear_en;
/*
* rdptr init and irq cannot be same due to h/w bug.
* if they are same, rdptr irqs could be missed.
*/
if (mfd->panel_info.lcd.primary_vsync_init ||
mfd->panel_info.lcd.primary_rdptr_irq) {
MDP_OUTP(MDP_BASE + 0x128,
mfd->panel_info.lcd.primary_vsync_init);
MDP_OUTP(MDP_BASE + 0x21C,
mfd->panel_info.lcd.primary_rdptr_irq);
} else {
MDP_OUTP(MDP_BASE + 0x128, 0);
MDP_OUTP(MDP_BASE + 0x21C, 1);
}

/*
* adjust start position and threshold to make sure
* write ptr follows read pts (TE is effective), and
* at the same write is not throttled(shorter dmap
* time)
*/
if (mfd->panel_info.lcd.primary_start_pos)
MDP_OUTP(MDP_BASE + 0x210,
mfd->panel_info.lcd.primary_start_pos);
else
MDP_OUTP(MDP_BASE + 0x210,
mfd->panel_info.lcd.v_back_porch +
mfd->panel_info.lcd.v_front_porch +
vsync_start_y_adjust);

if (mfd->panel_info.lcd.vsync_threshold_continue &&
mfd->panel_info.lcd.vsync_threshold_start)
MDP_OUTP(MDP_BASE + 0x200,
((mfd->panel_info.lcd.vsync_threshold_continue << 16) |
mfd->panel_info.lcd.vsync_threshold_start));
else
MDP_OUTP(MDP_BASE + 0x200,
((4 << 16) | mfd->panel_info.lcd.v_pulse_width));
} else
data &= ~tear_en;
MDP_OUTP(MDP_BASE + 0x20c, data);
mdp_clk_ctrl(0);
}