linux.git/drivers/net/ipa/gsi.c, branch v5.17 Linux kernel source tree net: ipa: support enhanced channel flow control 2021-11-26T04:04:52+00:00 Alex Elder elder@linaro.org 2021-11-24T19:44:16+00:00 fe68c43ce38865299de03b691e5069d3daca015a IPA v4.2 introduced GSI channel flow control, used instead of IPA endpoint DELAY mode to prevent a TX channel from injecting packets into the IPA core. It used a new FLOW_CONTROLLED channel state which could be entered using GSI generic commands. IPA v4.11 extended the channel flow control model. Rather than having a distinct FLOW_CONTROLLED channel state, each channel has a "flow control" property that can be enabled or not--independent of the channel state. The AP (or modem) can modify this property using the same GSI generic commands as before. The AP only uses channel flow control on modem TX channels, and only when recovering from a modem crash. The AP has no way to discover the state of a modem channel, so the fact that (starting with IPA v4.11) flow control no longer uses a distinct channel state is invisible to the AP. So enhanced flow control generally does not change the way AP uses flow control. There are a few small differences, however: - There is a notion of "primary" or "secondary" flow control, and when enabling or disabling flow control that must be specified in a new field in the GSI generic command register. For now, we always specify 0 (meaning "primary"). - When disabling flow control, it's possible a request will need to be retried. We retry up to 5 times in this case. - Another new generic command allows the current flow control state to be queried. We do not use this. Other than the need for retries, the code essentially works the same way as before. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
IPA v4.2 introduced GSI channel flow control, used instead of IPA
endpoint DELAY mode to prevent a TX channel from injecting packets
into the IPA core.  It used a new FLOW_CONTROLLED channel state
which could be entered using GSI generic commands.

IPA v4.11 extended the channel flow control model.  Rather than
having a distinct FLOW_CONTROLLED channel state, each channel has a
"flow control" property that can be enabled or not--independent of
the channel state.  The AP (or modem) can modify this property using
the same GSI generic commands as before.

The AP only uses channel flow control on modem TX channels, and only
when recovering from a modem crash.  The AP has no way to discover
the state of a modem channel, so the fact that (starting with IPA
v4.11) flow control no longer uses a distinct channel state is
invisible to the AP.  So enhanced flow control generally does not
change the way AP uses flow control.

There are a few small differences, however:
  - There is a notion of "primary" or "secondary" flow control, and
    when enabling or disabling flow control that must be specified
    in a new field in the GSI generic command register.  For now, we
    always specify 0 (meaning "primary").
  - When disabling flow control, it's possible a request will need
    to be retried.  We retry up to 5 times in this case.
  - Another new generic command allows the current flow control
    state to be queried.  We do not use this.

Other than the need for retries, the code essentially works the same
way as before.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ipa: introduce channel flow control 2021-11-26T04:03:20+00:00 Alex Elder elder@linaro.org 2021-11-24T19:44:15+00:00 4c9d631adbc277b33704a971cde6dd8ce44fbb8f One quirk for certain versions of IPA is that endpoint DELAY mode does not work properly. IPA DELAY mode prevents any packets from being delivered to the IPA core for processing on a TX endpoint. The AP uses DELAY mode when the modem crashes, to prevent modem TX endpoints from generating traffic during crash recovery. Without this, there is a chance the hardware will stall during recovery from a modem crash. To achieve a similar effect, a GSI FLOW_CONTROLLED channel state was created. A STARTED TX channel can be placed in FLOW_CONTROLLED state, which prevents the transfer of any more packets. A channel in FLOW_CONTROLLED state can be either returned to STARTED state, or can be transitioned to STOPPED state. Because this operates on GSI channels, two generic commands were added to allow the AP to control this state for modem channels (similar to the ALLOCATE and HALT channel commands). Previously the code assumed this quirk only applied to IPA v4.2. In fact, channel flow control (rather than endpoint DELAY mode) should be used for all versions *starting* with IPA v4.2. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
One quirk for certain versions of IPA is that endpoint DELAY mode
does not work properly.  IPA DELAY mode prevents any packets from
being delivered to the IPA core for processing on a TX endpoint.
The AP uses DELAY mode when the modem crashes, to prevent modem TX
endpoints from generating traffic during crash recovery.  Without
this, there is a chance the hardware will stall during recovery from
a modem crash.

To achieve a similar effect, a GSI FLOW_CONTROLLED channel state
was created.  A STARTED TX channel can be placed in FLOW_CONTROLLED
state, which prevents the transfer of any more packets.  A channel
in FLOW_CONTROLLED state can be either returned to STARTED state, or
can be transitioned to STOPPED state.

Because this operates on GSI channels, two generic commands were
added to allow the AP to control this state for modem channels
(similar to the ALLOCATE and HALT channel commands).

Previously the code assumed this quirk only applied to IPA v4.2.
In fact, channel flow control (rather than endpoint DELAY mode)
should be used for all versions *starting* with IPA v4.2.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ipa: GSI only needs one completion 2021-11-26T03:37:34+00:00 Alex Elder elder@linaro.org 2021-11-24T20:25:10+00:00 7ece9eaa3f16cec20f3138bab84f4fc98eff0ec8 A mutex ensures we never submit more than one GSI command of any kind at once. This means the per-channel and per-event ring completion structures provide no benefit. Instead, just use the single (existing) GSI completion to signal the completion of GSI commands of all types. This makes gsi_evt_ring_init() a trivial function with no inverse, so open-code it in its sole caller and get rid of the function. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
A mutex ensures we never submit more than one GSI command of any
kind at once.  This means the per-channel and per-event ring
completion structures provide no benefit.  Instead, just use the
single (existing) GSI completion to signal the completion of GSI
commands of all types.

This makes gsi_evt_ring_init() a trivial function with no inverse,
so open-code it in its sole caller and get rid of the function.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ipa: disable GSI interrupts while suspended 2021-08-04T09:12:05+00:00 Alex Elder elder@linaro.org 2021-08-03T14:01:03+00:00 45a42a3c50b583e78d96038e834909de627f87f1 Introduce new functions gsi_suspend() and gsi_resume(), which will disable the GSI interrupt handler after all endpoints are suspended and re-enable it before endpoints are resumed. This will ensure no GSI interrupt handler will fire when the hardware is suspended. Here's a little further explanation. There are seven GSI interrupt types, and most are disabled except when needed. - These two are not used (never enabled): GSI_INTER_EE_CH_CTRL GSI_INTER_EE_EV_CTRL - These two are only used to implement channel and event ring commands, and are only enabled while a command is underway: GSI_CH_CTRL GSI_EV_CTRL - The IEOB interrupt signals I/O completion. It will not fire when a channel is stopped (or "suspended"). GSI_IEOB - This interrupt is used to allocate or halt modem channels, and is only enabled while such a command is underway. GSI_GLOB_EE However it also is used to signal certain errors, and this could occur at any time. - The general interrupt signals general errors, and could occur at any time. GSI_GENERAL The purpose for this change is to ensure no global or general interrupts fire due to errors while the hardware is suspended. We enable the clock on resume, and at that time we can "handle" (at least report) these error conditions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Introduce new functions gsi_suspend() and gsi_resume(), which will
disable the GSI interrupt handler after all endpoints are suspended
and re-enable it before endpoints are resumed.  This will ensure no
GSI interrupt handler will fire when the hardware is suspended.

Here's a little further explanation.  There are seven GSI interrupt
types, and most are disabled except when needed.
  - These two are not used (never enabled):
      GSI_INTER_EE_CH_CTRL
      GSI_INTER_EE_EV_CTRL
  - These two are only used to implement channel and event ring
    commands, and are only enabled while a command is underway:
      GSI_CH_CTRL
      GSI_EV_CTRL
  - The IEOB interrupt signals I/O completion.  It will not fire
    when a channel is stopped (or "suspended").
      GSI_IEOB
  - This interrupt is used to allocate or halt modem channels,
    and is only enabled while such a command is underway.
      GSI_GLOB_EE
    However it also is used to signal certain errors, and this could
    occur at any time.
  - The general interrupt signals general errors, and could occur at
    any time.
      GSI_GENERAL

The purpose for this change is to ensure no global or general
interrupts fire due to errors while the hardware is suspended.
We enable the clock on resume, and at that time we can "handle"
(at least report) these error conditions.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: move gsi_irq_init() code into setup 2021-08-04T09:12:05+00:00 Alex Elder elder@linaro.org 2021-08-03T14:01:02+00:00 b176f95b5728e355ea6b61725cf240a575621e51 The GSI IRQ handler could be triggered as soon as it is registered with request_irq(). The handler function, gsi_isr(), touches hardware, meaning the IPA clock must be operational. The IPA clock is not operating when the handler is registered (in gsi_irq_init()), so this is a problem. Move the call to request_irq() for the GSI interrupt handler into gsi_irq_setup(), which is called when the IPA clock is known to be operational (and furthermore, the GSI firmware will have been loaded). Request the IRQ at the end of that function, after all interrupt types have been disabled and masked. Move the matching free_irq() call into gsi_irq_teardown(), and get rid of the now empty gsi_irq_exit(), Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
The GSI IRQ handler could be triggered as soon as it is registered
with request_irq().  The handler function, gsi_isr(), touches
hardware, meaning the IPA clock must be operational.  The IPA clock
is not operating when the handler is registered (in gsi_irq_init()),
so this is a problem.

Move the call to request_irq() for the GSI interrupt handler into
gsi_irq_setup(), which is called when the IPA clock is known to be
operational (and furthermore, the GSI firmware will have been
loaded).  Request the IRQ at the end of that function, after all
interrupt types have been disabled and masked.

Move the matching free_irq() call into gsi_irq_teardown(), and get
rid of the now empty gsi_irq_exit(),

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: have gsi_irq_setup() return an error code 2021-08-04T09:12:05+00:00 Alex Elder elder@linaro.org 2021-08-03T14:01:01+00:00 1657d8a45823429aabee0a3282b2d249abbd3831 Change gsi_irq_setup() so it returns an error value, and introduce gsi_irq_teardown() as its inverse. Set the interrupt type (IRQ rather than MSI) in gsi_irq_setup(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Change gsi_irq_setup() so it returns an error value, and introduce
gsi_irq_teardown() as its inverse.  Set the interrupt type (IRQ
rather than MSI) in gsi_irq_setup().

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: move some GSI setup functions 2021-08-04T09:12:05+00:00 Alex Elder elder@linaro.org 2021-08-03T14:01:00+00:00 a7860a5f898c9f5850ff9d72e6ee473791e5a6cf Move gsi_irq_setup() and gsi_ring_setup() so they're defined right above gsi_setup() where they're called. This is a trivial movement of code to prepare for upcoming patches. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Move gsi_irq_setup() and gsi_ring_setup() so they're defined right
above gsi_setup() where they're called.  This is a trivial movement
of code to prepare for upcoming patches.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: move version check for channel suspend/resume 2021-08-04T09:12:05+00:00 Alex Elder elder@linaro.org 2021-08-03T14:00:59+00:00 4a4ba483e4a56cb469f067493265f0173e06d060 Change the Boolean flags passed to __gsi_channel_start() and __gsi_channel_stop() so they represent whether the request is being made to implement suspend (versus stop) or resume (versus start). Then stop or start the channel for suspend/resume requests only if the hardware version indicates it should be done. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Change the Boolean flags passed to __gsi_channel_start() and
__gsi_channel_stop() so they represent whether the request is being
made to implement suspend (versus stop) or resume (versus start).

Then stop or start the channel for suspend/resume requests only if
the hardware version indicates it should be done.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: use gsi->version for channel suspend/resume 2021-08-04T09:12:05+00:00 Alex Elder elder@linaro.org 2021-08-03T14:00:58+00:00 decfef0fa6b21508657a6e54a01508196988bc95 The GSI layer has the IPA version now, so there's no need for version-specific flags to be passed from IPA. One instance of this is in gsi_channel_suspend() and gsi_channel_resume(), which indicate whether or not the endpoint suspend is implemented by GSI stopping the channel. We can make that determination based on gsi->version, eliminating the need for a Boolean flag in those functions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
The GSI layer has the IPA version now, so there's no need for
version-specific flags to be passed from IPA.  One instance of
this is in gsi_channel_suspend() and gsi_channel_resume(), which
indicate whether or not the endpoint suspend is implemented by
GSI stopping the channel.  We can make that determination based
on gsi->version, eliminating the need for a Boolean flag in those
functions.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: kill the remaining conditional validation code 2021-07-26T21:38:11+00:00 Alex Elder elder@linaro.org 2021-07-26T17:40:09+00:00 442d68ebf0927681e9405c3db8e9fafb754cb458 There are only a few remaining spots that validate IPA code conditional on whether a symbol is defined at compile time. The checks are not expensive, so just build them always. This completes the removal of all CONFIG_VALIDATE/CONFIG_VALIDATION IPA code. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
There are only a few remaining spots that validate IPA code
conditional on whether a symbol is defined at compile time.
The checks are not expensive, so just build them always.

This completes the removal of all CONFIG_VALIDATE/CONFIG_VALIDATION
IPA code.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>