On 11/30/2010 04:08 AM, David Brownell wrote: >>> Now force CS to be in inactive state only if it was >> inactive when it was suspended. > > Note that it's a bug if CS is active in > any suspend state (including OFF). That > strongly suggests $SUBJECT is an incomplete > workaround for that other bug... > It is not the case, at least it is not what we observed. In suspend state, CS is inactive. >>> >>> When SPI wake up from OFF mode, CS is in the wrong >> state: force it to the inactive state. > > Best report the bug that the suspend/OFF state > was mis-handled... That is, it didn't > correctly ENTER that OFF mode... > > In fact ... I'd like to see that fixed more > than the $SUBJECT issue, so the root cause > gets resolved... As far as I know, it enter correctly that OFF mode. It is only at wake up, that CS become active while there is no SPI message being processed. It is the point of my patch. My first patch version forced unconditionally CS to inactive state at wake up. It was correct from the point of view of the SPI but not for suspend/resume. Resume should only restore the state of the driver just before suspend. If resume force the inactive state it could mask a bug in the suspend path. But as I wrote before, as far as I know there is no bug when driver enter suspend mode, at this moment CS is inactive. > > CS should only be active while a SPI message > is being processed, and such processing must > have completed before suspend/OFF/... starts > I agree and this driver seems to respect this point. -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
