Hi Paul,
> While the patch did fix the issue for Anand, I guess it
> was because of the additional delay post reset, waiting on the
> RESETDONE bit and timing out, before accessing the i2c_con register.
I thought some more on this and the logic of the delay between the
SOFTRESET bit being set and an immediate register access did not make
much sense, because even polling on RESETDONE bit involves an immediate
i2c register access, albeit a different one.
I had a chat again with Anand this morning and realized the patch that
fixed the problems he saw on some customer hardware had changes from
both patch 1/2 and patch 2/2 from this series clubbed into one patch.
I seem to have split them into 2 patches later while posting it out
on the list.
So in all likelihood its the changes in patch 1/2 which made a
difference and the patch 2/2 was a result of my (wrong) analysis based
on code review.
The problems seen were extremely rare and not having access to those
few failing boards is making it difficult to re-validate with these
changes removed. However based on my analysis (hopefully right this time
:)) it seems safe to revert this patch in mainline.
Should I go ahead and send a revert for the -rc?
regards,
Rajendra
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
