Re: [PATCH] i2c: designware: use enable on resume instead initialization

2015-06-24 Thread christian . ruppert
Dear Lucas,

"De Marchi, Lucas"  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  wrote on 23.06.2015 
19:02:03:
> > > > On Tue, Jun 23, 2015 at 1:45 PM,   
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


Re: [PATCH] i2c: designware: use enable on resume instead initialization

2015-06-24 Thread mika.westerb...@linux.intel.com
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

2015-06-24 Thread De Marchi, Lucas
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  wrote on 23.06.2015 19:02:03:
> > > On Tue, Jun 23, 2015 at 1:45 PM,   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

2015-06-24 Thread Mika Westerberg
On Wed, Jun 24, 2015 at 09:36:43AM +0200, christian.rupp...@alitech.com wrote:
> Dear Lucas,
> 
> Lucas De Marchi  wrote on 23.06.2015 19:02:03:
> > On Tue, Jun 23, 2015 at 1:45 PM,   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

2015-06-24 Thread christian . ruppert
Dear Lucas,

Lucas De Marchi  wrote on 23.06.2015 19:02:03:
> On Tue, Jun 23, 2015 at 1:45 PM,   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