On Wed, 2015-06-24 at 14:27 +0300, Mika Westerberg wrote:
> On Wed, Jun 24, 2015 at 09:36:43AM +0200, christian.ruppert@xxxxxxxxxxx wrot
> e:
> > Dear Lucas,
> >
> > Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> wrote on 23.06.2015 19:02:03:
> > > On Tue, Jun 23, 2015 at 1:45 PM, <christian.ruppert@xxxxxxxxxxx> 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 Marchi��.n��������+%������w��{.n�����{��-��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
