Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Fri, Apr 01, 2016 at 12:02:56AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/19/2015 06:56 PM, Wolfram Sang wrote:
> 
> >From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> >If we don't clear START generation as soon as possible, it may cause
> >another message to be generated, e.g. when receiving NACK in address
> >phase. To keep the race window as small as possible, we clear it right
> >at the beginning of the interrupt. We don't need any checks since we
> >always want to stop START and STOP generation on the next occasion after
> >we started it.
> >
> >This patch improves the situation but sadly does not completely fix it.
> >It is still to be researched if we can do better given this HW design.
> >
> >Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> 
>    Thanks for a great work, Wolfram!
>    We need this patch in -stable kernels. The R-Car audio just doesn't work
> without it...

Really only this patch? IIRC my tests showed that if you don't remove
the spinlocks (patch 4), the interrupt latency will already be too high
again. In any case, you'd need to do some careful backporting to rip
this out of the whole refactoring series. But maybe you did that already
and have good experiences?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Sergei Shtylyov]

Hello.

On 04/01/2016 01:48 AM, Wolfram Sang wrote:

>>> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>>
>>> If we don't clear START generation as soon as possible, it may cause
>>> another message to be generated, e.g. when receiving NACK in address
>>> phase. To keep the race window as small as possible, we clear it right
>>> at the beginning of the interrupt. We don't need any checks since we
>>> always want to stop START and STOP generation on the next occasion after
>>> we started it.
>>>
>>> This patch improves the situation but sadly does not completely fix it.
>>> It is still to be researched if we can do better given this HW design.
>>>
>>> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>
>>     Thanks for a great work, Wolfram!
>>     We need this patch in -stable kernels. The R-Car audio just doesn't work
>> without it...

> Really only this patch?

    Well, my "reverse" bisection pointed at it. :-)

> IIRC my tests showed that if you don't remove
> the spinlocks (patch 4), the interrupt latency will already be too high
> again.

    Thank you for the valuable info!

> In any case, you'd need to do some careful backporting to rip
> this out of the whole refactoring series.

    Yes, I've already figured that.

> But maybe you did that already
> and have good experiences?

    Not yet, I will report back after more backporting/testing.

MBR, Sergei

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]


> >IIRC my tests showed that if you don't remove
> >the spinlocks (patch 4), the interrupt latency will already be too high
> >again.
> 
>    Thank you for the valuable info!

Oh, and add patch 6 to it. The context switches are a major problem in
this.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Sergei Shtylyov]

On 04/01/2016 11:14 PM, Wolfram Sang wrote:
>
>>> IIRC my tests showed that if you don't remove
>>> the spinlocks (patch 4), the interrupt latency will already be too high
>>> again.
>>
>>     Thank you for the valuable info!
>
> Oh, and add patch 6 to it. The context switches are a major problem in
> this.

    Thanks again! I ended up backporting all the patches up to #9. Not sure 
it'd be acceptable for the -stable kernels since there's a lot of refactors 
involved...

MBR, Sergei

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]


>    Thanks again! I ended up backporting all the patches up to #9. Not sure
> it'd be acceptable for the -stable kernels since there's a lot of refactors
> involved...

That's what I thought, too.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Sergei Shtylyov]

On 4/2/2016 10:27 AM, Wolfram Sang wrote:

>>     Thanks again! I ended up backporting all the patches up to #9. Not sure
>> it'd be acceptable for the -stable kernels since there's a lot of refactors
>> involved...
>
> That's what I thought, too.

    And I still don't feel good about the patch removing the spinlock -- I'm 
not sure it's SMP-safe...

MBR, Sergei

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]


>    And I still don't feel good about the patch removing the spinlock -- I'm
> not sure it's SMP-safe...

In what scenario?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Sergei Shtylyov]

On 04/03/2016 11:25 AM, Wolfram Sang wrote:

>>     And I still don't feel good about the patch removing the spinlock -- I'm
>> not sure it's SMP-safe...
>
> In what scenario?

    I've reviewed the patches once again and it looked like they are safe.

MBR, Sergei

Re: [PATCH v3 09/11] i2c: rcar: revoke START request early

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]


> >>    And I still don't feel good about the patch removing the spinlock -- I'm
> >>not sure it's SMP-safe...
> >
> >In what scenario?
> 
>    I've reviewed the patches once again and it looked like they are safe.

Thanks.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]