linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Execute spi transfers inside FIQ (NMI) or panic
@ 2020-02-25 13:27 Herbrechtsmeier Dr.-Ing. , Stefan
       [not found] ` <b22800b8-9c03-63a5-7ade-d8b63c562580-2t/0UIm1CeVDOHtkgc7UlQ@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Herbrechtsmeier Dr.-Ing. , Stefan @ 2020-02-25 13:27 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA

Hi,

would it be acceptable to add an additional function to the struct 
spi_controller which handle a transfer inside a NMI context or a panic? 
The new function will transfer data via register polling without any lock.

I must execute an SPI transfer inside a fast interrupt request (FIQ) 
handler or a panic. The FIQ is handled as a non-maskable interrupt 
(NMI). Both the panic and the NMI doesn't support any interrupts.

The background of the request is a non-volatile SPI memory with cached 
date in system memory. The cache must be synchronized back to the SPI 
memory after a power failure or panic.

Regards
   Stefan Herbrechtsmeier

**

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Execute spi transfers inside FIQ (NMI) or panic
       [not found] ` <b22800b8-9c03-63a5-7ade-d8b63c562580-2t/0UIm1CeVDOHtkgc7UlQ@public.gmane.org>
@ 2020-02-25 15:53   ` Mark Brown
       [not found]     ` <20200225155354.GF4633-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Brown @ 2020-02-25 15:53 UTC (permalink / raw)
  To: Herbrechtsmeier Dr.-Ing. , Stefan; +Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA

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

On Tue, Feb 25, 2020 at 02:27:27PM +0100, Herbrechtsmeier Dr.-Ing. , Stefan wrote:

> would it be acceptable to add an additional function to the struct
> spi_controller which handle a transfer inside a NMI context or a panic? The
> new function will transfer data via register polling without any lock.

That would need to happen as part of a wider change that made it
possible to use such an interface safely and did so, off the top of my
head it's not immediately obvious how one would do that.  You'd need to
get the hardware into a sensible state and then do whatever needs doing
with some cooperation from the client driver in all this which is a bit
of an ask.  It's not a trivial bit of work, but I do see the use case
and it's absolutely valid.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Execute spi transfers inside FIQ (NMI) or panic
       [not found]     ` <20200225155354.GF4633-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
@ 2020-02-26  7:36       ` Herbrechtsmeier Dr.-Ing. , Stefan
       [not found]         ` <d07a46e6-6c8f-c4eb-0ed1-d57b7604a5be-2t/0UIm1CeVDOHtkgc7UlQ@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Herbrechtsmeier Dr.-Ing. , Stefan @ 2020-02-26  7:36 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA

Am 25.02.2020 um 16:53 schrieb Mark Brown:
> On Tue, Feb 25, 2020 at 02:27:27PM +0100, Herbrechtsmeier Dr.-Ing. , Stefan wrote:
>
>> would it be acceptable to add an additional function to the struct
>> spi_controller which handle a transfer inside a NMI context or a panic? The
>> new function will transfer data via register polling without any lock.
> That would need to happen as part of a wider change that made it
> possible to use such an interface safely and did so, off the top of my
> head it's not immediately obvious how one would do that.  You'd need to
> get the hardware into a sensible state and then do whatever needs doing
> with some cooperation from the client driver in all this which is a bit
> of an ask.  It's not a trivial bit of work, but I do see the use case
> and it's absolutely valid.

I see two possible solutions.
a) The complexity is handled inside the client. The client uses the 
controller exclusive and isn’t allowed to use the new panic transfer 
during a normal transfer.
b) The complexity is handled inside the controller. The controller is 
shared between multiple slaves and a panic transfer must abort a running 
transfer.

The first solution keeps the controller driver simple because only a new 
polled transfer is needed. But the prepare and unprepare functions must 
be lock free and power management must be handled lock free to be reused.

The second solution could lead to code duplication because an addition 
panic prepare function must setup the controller from any state and must 
abort a running transfer. Especially the abort could be complex and 
difficult to test. Otherwise the new functionality could be used without 
any constraints.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Execute spi transfers inside FIQ (NMI) or panic
       [not found]         ` <d07a46e6-6c8f-c4eb-0ed1-d57b7604a5be-2t/0UIm1CeVDOHtkgc7UlQ@public.gmane.org>
@ 2020-02-26 11:33           ` Mark Brown
       [not found]             ` <20200226113333.GC4136-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Brown @ 2020-02-26 11:33 UTC (permalink / raw)
  To: Herbrechtsmeier Dr.-Ing. , Stefan; +Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA

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

On Wed, Feb 26, 2020 at 08:36:37AM +0100, Herbrechtsmeier Dr.-Ing. , Stefan wrote:

> I see two possible solutions.
> a) The complexity is handled inside the client. The client uses the
> controller exclusive and isn’t allowed to use the new panic transfer during
> a normal transfer.

Then someone builds a system with two devices attached to a single SPI
controller...  besides, you've got no mechanism for controlling when a
kernel might panic or power might be lost.  I'm not sure a scheme that
relies on being able to control when stuff happens is going to be what
you need.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Execute spi transfers inside FIQ (NMI) or panic
       [not found]             ` <20200226113333.GC4136-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
@ 2020-02-26 15:28               ` Herbrechtsmeier Dr.-Ing. , Stefan
  0 siblings, 0 replies; 5+ messages in thread
From: Herbrechtsmeier Dr.-Ing. , Stefan @ 2020-02-26 15:28 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA

Am 26.02.2020 um 12:33 schrieb Mark Brown:
> On Wed, Feb 26, 2020 at 08:36:37AM +0100, Herbrechtsmeier Dr.-Ing. , Stefan wrote:
>
>> I see two possible solutions.
>> a) The complexity is handled inside the client. The client uses the
>> controller exclusive and isn’t allowed to use the new panic transfer during
>> a normal transfer.
> Then someone builds a system with two devices attached to a single SPI
> controller...  besides, you've got no mechanism for controlling when a
> kernel might panic or power might be lost.  I'm not sure a scheme that
> relies on being able to control when stuff happens is going to be what
> you need.

In my case this works because I read from the device during probe and 
write to the device during a panic or after power failure. But I 
understand that this isn't a generic solution.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-02-26 15:28 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-25 13:27 Execute spi transfers inside FIQ (NMI) or panic Herbrechtsmeier Dr.-Ing. , Stefan
     [not found] ` <b22800b8-9c03-63a5-7ade-d8b63c562580-2t/0UIm1CeVDOHtkgc7UlQ@public.gmane.org>
2020-02-25 15:53   ` Mark Brown
     [not found]     ` <20200225155354.GF4633-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2020-02-26  7:36       ` Herbrechtsmeier Dr.-Ing. , Stefan
     [not found]         ` <d07a46e6-6c8f-c4eb-0ed1-d57b7604a5be-2t/0UIm1CeVDOHtkgc7UlQ@public.gmane.org>
2020-02-26 11:33           ` Mark Brown
     [not found]             ` <20200226113333.GC4136-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2020-02-26 15:28               ` Herbrechtsmeier Dr.-Ing. , Stefan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).