[HD2 Android NAND Development] speedyracer5:
Basically, as we all know there is a delay when turning on the screen. I have been looking through various kernel files and trying to find the source of the problem. and I believe that I have found part of the problem!

The first errors that I found happened each time the screen was turned on, in the log it showed....

[ERROR] msm_i2c msm_i2c.0: error, status 63c8 (5C)

[ERROR] msm_i2c msm_i2c.0: Error during data xfer (-5) (5C)

[ERROR] msm_i2c msm_i2c.0: error, status e3c8 (34)

[ERROR] msm_i2c msm_i2c.0: Error during data xfer (-5) (34)

This lead me to believe that it was an issue with the msm files in the kernel...

I then found two of the errors in a file I found on the HD2 Kernel GitHub... the link to the file is also below....

https://github.com/charansingh/cm-kernel/blob/master/drivers/i2c/busses/i2c-msm.c

if (ret < 0) {
dev_err(dev->dev, "Error during data xfer (%d) @%02X\n", ret, msgs->addr);
msm_i2c_recover_bus_busy(dev);
}

Now I have started C robotics programming quite recently so I was hoping that it would help me here! This loop obviously checks if the variable ret is < 0 and if it is it will display an error message! Now earlier in the code ret was set using

ret = msm_i2c_poll_notbusy(dev, 1);

This led me onto the function

msm_i2c_poll_notbusy....

msm_i2c_poll_notbusy(struct msm_i2c_dev *dev, int warn)
{
uint32_t retries = 0;

while (retries != 200) {
uint32_t status = readl(dev->base + I2C_STATUS);

if (!(status & I2C_STATUS_BUS_ACTIVE)) {
if (retries && warn)
dev_warn(dev->dev,
"Warning bus was busy (%d)\n", retries);
return 0;
}
if (retries++ > 100)
usleep_range(100, 200);
}
dev_err(dev->dev, "Error waiting for notbusy (%d)\n", warn);
return -ETIMEDOUT;
}

As far as I can see, with no kernel programming history in my life, it sets the unsigned integer retries to 0, then starts a while loop testing

readl(dev->base + I2C_STATUS)& I2C_STATUS_BUS_ACTIVE

If the result of this is false it will return that the bus was busy for so many tries, it then exits out of the while loop returning control to the rest of the function...

otherwise ( in our case ) it will increase the variable retries by one and if there have been more than 100 retries it will have a 10 millisecond delay before returning control back to the top of the while loop. After 200 retries the while loop is no longer valid and then it will exit...

The cause for the around 2 second delay is partially due to the phone waiting until this loop has finished before it has turned the screen fully on! the 100 tries of the 10 millisecond delay equates for 1 second of the delay, so if we could fix the loop problem this WILL increase the speed at which the screen turns on... the other error is caused by

if (status & I2C_STATUS_ERROR_MASK)
goto out_err;

out_err:
dev_err(dev->dev, "error, status %x (%02X)\n", status, dev->msg->addr);
dev->ret = -EIO;

I do not believe that this error is causing a slowdown but they are related.

The problem always involves the variable status so this probably gives a good idea that whatever sets status must be incorrect...

Anyhow I have never touched kernel scripting in my life, I am 15, so I may be completely wrong, but from what I can see I hope that I am at least partially right!