Hi Wolfram,
On 07/10/2015 12:09 PM, Wolfram Sang wrote:
>
>> 60 s sounds way too much and actually I simply don't believe this is
>> the root cause. If I take a look into the driver, then I see, that
>
> I agree, this is just a workaround.
>
>> the design is not really the best. The whole IRQ
On 07/10/2015 04:26 PM, Alexander Sverdlin wrote:
> Hi!
>
> On 10/07/15 15:17, ext Vignesh R wrote:
I would propose you to throw away spinlocks. Convert threaded IRQ to
Agree. Looks like spinlock is not needed.
>> just one hardirq handler. And continue debugging. You will reduce the
Hi,
On 07/10/2015 06:56 PM, Alexander Sverdlin wrote:
> Hi!
>
> On 10/07/15 15:17, ext Vignesh R wrote:
I would propose you to throw away spinlocks. Convert threaded IRQ to
>> just one hardirq handler. And continue debugging. You will reduce the
>> load of the system with the above
Hi!
On 10/07/15 15:17, ext Vignesh R wrote:
>>> I would propose you to throw away spinlocks. Convert threaded IRQ to
>>> >> just one hardirq handler. And continue debugging. You will reduce the
>>> >> load of the system with the above measures, maybe it will not happen
>>> >> any more, maybe
On 07/10/2015 02:39 PM, Wolfram Sang wrote:
>
>> 60 s sounds way too much and actually I simply don't believe this is
>> the root cause. If I take a look into the driver, then I see, that
>
> I agree, this is just a workaround.
>
Yes, this is a workaround. I thought this is simpler change
> 60 s sounds way too much and actually I simply don't believe this is
> the root cause. If I take a look into the driver, then I see, that
I agree, this is just a workaround.
> the design is not really the best. The whole IRQ handling could be
> actually performed in hard IRQ handler, without
Hi Vignesh,
On 10/07/15 07:09, ext Vignesh R wrote:
> When system is under load and there is an i2c transaction running
> following warning appears on the console:
>
> [ 730.003617] omap_i2c 4807.i2c: controller timed out
> [ 731.023643] omap_i2c 4807.i2c: controller timed out
>
>
Vignesh,
On 10/07/15 08:09, Vignesh R wrote:
> When system is under load and there is an i2c transaction running
> following warning appears on the console:
>
> [ 730.003617] omap_i2c 4807.i2c: controller timed out
> [ 731.023643] omap_i2c 4807.i2c: controller timed out
>
> This is
Hi Vignesh,
On 10/07/15 07:09, ext Vignesh R wrote:
When system is under load and there is an i2c transaction running
following warning appears on the console:
[ 730.003617] omap_i2c 4807.i2c: controller timed out
[ 731.023643] omap_i2c 4807.i2c: controller timed out
This is
60 s sounds way too much and actually I simply don't believe this is
the root cause. If I take a look into the driver, then I see, that
I agree, this is just a workaround.
the design is not really the best. The whole IRQ handling could be
actually performed in hard IRQ handler, without
Vignesh,
On 10/07/15 08:09, Vignesh R wrote:
When system is under load and there is an i2c transaction running
following warning appears on the console:
[ 730.003617] omap_i2c 4807.i2c: controller timed out
[ 731.023643] omap_i2c 4807.i2c: controller timed out
This is because,
On 07/10/2015 02:39 PM, Wolfram Sang wrote:
60 s sounds way too much and actually I simply don't believe this is
the root cause. If I take a look into the driver, then I see, that
I agree, this is just a workaround.
Yes, this is a workaround. I thought this is simpler change and can go
Hi!
On 10/07/15 15:17, ext Vignesh R wrote:
I would propose you to throw away spinlocks. Convert threaded IRQ to
just one hardirq handler. And continue debugging. You will reduce the
load of the system with the above measures, maybe it will not happen
any more, maybe you'll figure out that
Hi,
On 07/10/2015 06:56 PM, Alexander Sverdlin wrote:
Hi!
On 10/07/15 15:17, ext Vignesh R wrote:
I would propose you to throw away spinlocks. Convert threaded IRQ to
just one hardirq handler. And continue debugging. You will reduce the
load of the system with the above measures, maybe it
Hi Wolfram,
On 07/10/2015 12:09 PM, Wolfram Sang wrote:
60 s sounds way too much and actually I simply don't believe this is
the root cause. If I take a look into the driver, then I see, that
I agree, this is just a workaround.
the design is not really the best. The whole IRQ handling
On 07/10/2015 04:26 PM, Alexander Sverdlin wrote:
Hi!
On 10/07/15 15:17, ext Vignesh R wrote:
I would propose you to throw away spinlocks. Convert threaded IRQ to
Agree. Looks like spinlock is not needed.
just one hardirq handler. And continue debugging. You will reduce the
load of the
16 matches
Mail list logo
