Hi Wolfram, On Tue, Apr 16, 2019 at 12:57:22PM +0200, Wolfram Sang wrote: > > > I have used them to test your changes and my usecase on my available > > hardware setup: an i.MX6 Solo (phyCORE-i.MX6). > > Good to have another platform tested. > > > In general: Great stuff! And I vote for inclusion :-) > > Cool! > > > > a) we decided to respect the current locking scheme and to not give atomic > > > transfers a priority. The code needed for that would have been either > > > incomplete or very invasive. And we cannot guarantee successful transfers > > > anyhow. See [1] for the discussion and other write-ups for design choices. > > > > Ack. I can just confirm that the mentioned locking issues are a real. I > > could not reproduce them on my single core ARM SoC, but on a multi core > > ARM system, e.g. the CPU frequency scaler is maybe holding the I2C > > transfer mutex, while the system is going to restart. > > There is freq scaling going on when 'system_state > SYSTEM_RUNNING'? Is > this a guess or confirmed? Only some memories in my head that the frequency scaler caused I2C adapter locking issues on a multi core device. So read it as a 'guess'. But since I don't like unsolved mysteries in software engineering, I'm now trying to get an i.MX6 Quad device to verify this. I have a very kind donor :-) Kind regards, Stefan
