Re: [PATCH] i2c: designware: use enable on resume instead initialization
Dear Lucas, Lucas De Marchi lucas.de.mar...@gmail.com wrote on 23.06.2015 19:02:03: On Tue, Jun 23, 2015 at 1:45 PM, christian.rupp...@alitech.com wrote: Hello, Christian Ruppert/ALi_GVA/ALi wrote on 10.06.2015 17:05:16: [...] The result is not very encouraging: Out of five (identical) designware i2c controllers we have on my test SOC, the first one initialises properly but the second one gets stuck in the famous irq loop right away when the module is enabled in i2c_dw_init. The system never gets around to try Are you using the pci or platform driver? I noticed yesterday the pci version is failing here with a NULL pointer dereference. The test was performed with the platform driver (instantiated through device tree). I just re-checked and the ultimate problem which hangs/kills the system in my case is the IRQ loop. I haven't observed any NULL pointer dereferences on the road. Greetings, Christian -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: designware: use enable on resume instead initialization
On Wed, 2015-06-24 at 14:27 +0300, Mika Westerberg wrote:
On Wed, Jun 24, 2015 at 09:36:43AM +0200, christian.rupp...@alitech.com wrot
e:
Dear Lucas,
Lucas De Marchi lucas.de.mar...@gmail.com wrote on 23.06.2015 19:02:03:
On Tue, Jun 23, 2015 at 1:45 PM, christian.rupp...@alitech.com wrote:
Hello,
Christian Ruppert/ALi_GVA/ALi wrote on 10.06.2015 17:05:16:
[...]
The result is not very encouraging: Out of five (identical) designware
i2c
controllers we have on my test SOC, the first one initialises properly
but
the second one gets stuck in the famous irq loop right away when the
module is enabled in i2c_dw_init. The system never gets around to try
Are you using the pci or platform driver? I noticed yesterday the pci
version is failing here with a NULL pointer dereference.
The test was performed with the platform driver (instantiated through
device tree).
I just re-checked and the ultimate problem which hangs/kills the system in
my case is the IRQ loop.
I haven't observed any NULL pointer dereferences on the road.
Thanks Christian for testing.
Since the patch causes problems on your hardware, I don't think it is
good idea to merge it.
Yeah, but it would be bad to ignore the problem as well. The way it is now
kills any possibility of using DW controller for reading sensors like
gyroscope, accelerometer, barometer that have higher sampling rate etc. I'll
try to come up with a new patch but since I can't reproduce the problem here
it'd be good to know if there's any means for me to test. What do you think
that could be done? Maybe putting the controller to sleep only in case of
errors?
thanks
--
Lucas De
MarchiN�r��yb�X��ǧv�^�){.n�+{��g��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH] i2c: designware: use enable on resume instead initialization
On Wed, Jun 24, 2015 at 09:36:43AM +0200, christian.rupp...@alitech.com wrote: Dear Lucas, Lucas De Marchi lucas.de.mar...@gmail.com wrote on 23.06.2015 19:02:03: On Tue, Jun 23, 2015 at 1:45 PM, christian.rupp...@alitech.com wrote: Hello, Christian Ruppert/ALi_GVA/ALi wrote on 10.06.2015 17:05:16: [...] The result is not very encouraging: Out of five (identical) designware i2c controllers we have on my test SOC, the first one initialises properly but the second one gets stuck in the famous irq loop right away when the module is enabled in i2c_dw_init. The system never gets around to try Are you using the pci or platform driver? I noticed yesterday the pci version is failing here with a NULL pointer dereference. The test was performed with the platform driver (instantiated through device tree). I just re-checked and the ultimate problem which hangs/kills the system in my case is the IRQ loop. I haven't observed any NULL pointer dereferences on the road. Thanks Christian for testing. Since the patch causes problems on your hardware, I don't think it is good idea to merge it. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: designware: use enable on resume instead initialization
On Wed, Jun 24, 2015 at 12:56:19PM +, De Marchi, Lucas wrote: Yeah, but it would be bad to ignore the problem as well. The way it is now kills any possibility of using DW controller for reading sensors like gyroscope, accelerometer, barometer that have higher sampling rate etc. I'll try to come up with a new patch but since I can't reproduce the problem here it'd be good to know if there's any means for me to test. What do you think that could be done? Maybe putting the controller to sleep only in case of errors? Instead of disabling the adapter after each transfer, I wonder if it is enough if we just mask all interrupts? That should also prevent the interrupt loop Christian is seeing on his hardware. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: designware: use enable on resume instead initialization
Dear Lucas, De Marchi, Lucas lucas.demar...@intel.com wrote on 24.06.2015 14:56:19: On Wed, 2015-06-24 at 14:27 +0300, Mika Westerberg wrote: On Wed, Jun 24, 2015 at 09:36:43AM +0200, christian.rupp...@alitech.com wrot e: Dear Lucas, Lucas De Marchi lucas.de.mar...@gmail.com wrote on 23.06.2015 19:02:03: On Tue, Jun 23, 2015 at 1:45 PM, christian.rupp...@alitech.com wrote: Hello, Christian Ruppert/ALi_GVA/ALi wrote on 10.06.2015 17:05:16: [...] The result is not very encouraging: Out of five (identical) designware i2c controllers we have on my test SOC, the first one initialises properly but the second one gets stuck in the famous irq loop right away when the module is enabled in i2c_dw_init. The system never gets around to try Are you using the pci or platform driver? I noticed yesterday the pci version is failing here with a NULL pointer dereference. The test was performed with the platform driver (instantiated through device tree). I just re-checked and the ultimate problem which hangs/kills thesystem in my case is the IRQ loop. I haven't observed any NULL pointer dereferences on the road. Thanks Christian for testing. Since the patch causes problems on your hardware, I don't think it is good idea to merge it. Yeah, but it would be bad to ignore the problem as well. The way it is now kills any possibility of using DW controller for reading sensors like gyroscope, accelerometer, barometer that have higher sampling rate etc. I'll try to come up with a new patch but since I can't reproduce the problem here it'd be good to know if there's any means for me to test. I'll analyse the problem a bit further and send you a description (sda and scl state at enable time) as soon as I can put my hands on an oscilloscope one evening. Greetings, Christian -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
