On Thu, Aug 02, 2012 at 07:58:24AM +0200, Ola Lilja wrote:
Accusing me of having "no interest in fixing the driver" is just absurd regarding the time I've spent on this. I'm also still driving for
Sorry, this is more directed at the current round of fixes that are being sent than the driver itself - the patches to bodge around the issue are being pushed fairly aggressively as an urgent fix without even mentioning what the issue is. I don't have any concerns with the driver, only with the way it's being fixed.
Regarding the problem with the failing DAPM-widget I can probably guess What is going wrong when Lee is trying it out. There will be two failing clock-supply widgets due to the fact that on the mainline-code these clocks simply is not there yet. I have, of course, tested this driver before submitting it, and I wouldn't dream on submitting a driver where there were failing widgets/routes. Internally, I have put a patch with our clock-tree for Ux500 on, but this is not mainline-quality code and that is
This sort of reliance on out of tree patches which any real user of the device would be expected to have sounds like exactly the sort of thing I'd expect to have caused an issue like this, and obviously the fix here is to get the clocks in place (even if just as stubs, though I'd expect there to be a major impact on the functionality of the device if it's not clocked...) rather than to just bodge out the error checking.
It does also suggest that the DT binding for this device will need to include the setup of these clocks (I believe the clock bindings for DT have just gone into mainline this merge window but I'd need to check).