The voltage used in the constant voltage phase of the charging
exist in struct power_supply_battery_info as
constant_charge_voltage_max_uv.
Switch the custom property normal_vol_lvl to this and
consequentially change everything that relates to this value
over to using microvolts rather than millivolts so
we align internal representation of current with the
power core. Prefix every variable we change with *_uv
to indicate the unit everywhere but also to make sure
we do not miss any outlier.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The current used in the constant current phase of the charging
exist in struct power_supply_battery_info as
constant_charge_current_max_ua.
Switch the custom property max_out_curr to this and
consequentally change everything that relates to this value
over to using microamperes rather than milliamperes so
we align internal representation of current with the
power core. Prefix every variable we change with *_ua
to indicate the unit everywhere but also to make sure
we do not miss any outlier.
Drop some duplicate unused defines in a header.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The recharge capacity is the hysteresis level for a charger to
restart when a battery does not support maintenance charging.
All products using the AB8500 have batteries supporting
maintenace charging and all code has always set this to 95%.
Turn it into a constant.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The AB8500 custom termination current can be replaced by the
corresponding struct power_supply_battery_info field.
Remove the struct member and amend the code to use the
standard property.
Add *_ua suffix for clarity and to make sure we have
changed all code sites using this member.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The nominal internal resistance isn't used by the AB8500
charging code, instead this resistance is measured continuously,
but we anyways migrate this to the standard property in
struct power_supply_battery_info.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
We were assigning some battery data state in probe() but
this is insecure as it depends on the proper probe order
between the components: the charger must probe first so
that the battery data is populated. Move the init to
the bind() call which is certain to happen after the
probe of the master and all components has happened.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The nominal voltage in this charge driver corresponds to
both the voltage_min_design_uv and voltage_max_design_uv
of struct power_supply_battery_info so assign both if this
is undefined.
The overcharge max voltage (when the charger should cut off)
is migrated at the same time so we move both voltages to
struct power_supply_battery_info.
Adjust the code to deal directly with the microvolt values
instead of converting them to millivolts.
Add *_uv suffixes for clarity and to make sure we have
changed all code sites using this member.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The AB8500 custom battery type can be replaced by the
corresponding struct power_supply_battery_info field.
Remove the struct member and amend the code to use the
standard property.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Now that we know that we have only one battery type to
deal with we can proceed to transfer properties to
struct power_supply_battery_info.
The designed capacity for the battery was in a custom field
of the custom battery type in mAh, transfer this to the
standard charge_full_design_uah property in
struct power_supply_battery_info and augment the code
accordingly.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The code was going through hoops and loops to detect what
battery is connected and check the resistance for this battery
etc.
Skip this trouble: we will support one battery (currently
"unknown") then we will find the connected battery in the
device tree using a compatible string. The battery resistance
may be used to double-check that the right battery is
connected.
Convert the array of battery types into one battery type so
we can next move over the properties of this one type into
the standard struct power_supply_battery_info.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The code tries to detect a lot of battery variants on the reference
designs, but we are not using the reference designs in practice, we
are using real products such as Samsung Phones.
The reference design with no battery plugged in will be detected as
a LIPO battery with a thermistor on the batctrl pin so we will
assume this and later on we can support other types through the
device tree if we want, just like the products do.
Drop the tables for external thermistor, only keep the internal
thermistor tables that we will use as default.
We can delete the assignment of the temperature to resistance table
since the default will be the only and correct option.
Also get rid of some unused variables and unused exports.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Instead of storing the temperature limits in our custom
struct struct ab8500_bm_data, make struct power_supply_battery_info
a member of this and store the min and max temperatures inside
that struct as the temp_min/temp_max and
temp_alert_min/temp_alert_max respectively.
The values can be assigned from the device tree, but if
not present will be set to the same defaults as are currently
in the code.
This way we start to move over to using
struct power_supply_battery_info and make it possible to move
the data over to the device tree and we will move piece by
piece toward using the standard info struct.
Temperature hysteresis is currently not supported by the
standard struct but we move the assignment here as well so
that we have all parameterization in one spot.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The two tables for input and output current translation from
register values does not need to be passed around from the
battery manager data. Just push it down into the charger code
where it is used, like other tables in that code.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This deploys the core battery DT parser to read the basic properties
of the battery. We only use very little of it as we start out, but
we will improve as we go along.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The bit of documentation that talks about TIF_FOREIGN_FPSTATE
does not mention the ungodly tricks that KVM plays with this flag.
Try and document this for the posterity.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Now that we can track an equivalent of TIF_FOREIGN_FPSTATE, drop
the mapping of current's thread_info at EL2.
Signed-off-by: Marc Zyngier <maz@kernel.org>
We currently have to maintain a mapping the thread_info structure
at EL2 in order to be able to check the TIF_FOREIGN_FPSTATE flag.
In order to eventually get rid of this, start with a vcpu flag that
shadows the thread flag on each entry into the hypervisor.
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Now that we don't have any users left for __sve_save_state, remove
it altogether. Should we ever need to save the SVE state from the
hypervisor again, we can always re-introduce it.
Suggested-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
The lpspi on i.MX8ULP is derived from i.MX7ULP, it uses two
compatible strings, so update the comaptible string for i.MX8ULP.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211120113454.785997-4-peng.fan@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The same logic is used in spi_match_id() and in the __spi_register_driver().
By switching the former from taking struct spi_device * to const char * as
the second parameter we may deduplicate the code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211119173718.52938-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This doc is fairly outdated and only uses legacy device instantiation
terminology. Let us update it and also mention the OF and ACPI device
tables, to make easier for users to figure out how should be defined.
Also, mention that devices bind could be done in user-space now using
the "driver_override" sysfs entry.
Suggested-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211119121139.2412761-1-javierm@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Nikolay Aleksandrov says:
====================
net: nexthop: fix refcount issues when replacing groups
This set fixes a refcount bug when replacing nexthop groups and
modifying routes. It is complex because the objects look valid when
debugging memory dumps, but we end up having refcount dependency between
unlinked objects which can never be released, so in turn they cannot
free their resources and refcounts. The problem happens because we can
have stale IPv6 per-cpu dsts in nexthops which were removed from a
group. Even though the IPv6 gen is bumped, the dsts won't be released
until traffic passes through them or the nexthop is freed, that can take
arbitrarily long time, and even worse we can create a scenario[1] where it
can never be released. The fix is to release the IPv6 per-cpu dsts of
replaced nexthops after an RCU grace period so no new ones can be
created. To do that we add a new IPv6 stub - fib6_nh_release_dsts, which
is used by the nexthop code only when necessary. We can further optimize
group replacement, but that is more suited for net-next as these patches
would have to be backported to stable releases.
v2: patch 02: update commit msg
patch 03: check for mausezahn before testing and make a few comments
more verbose
[1]
This info is also present in patch 02's commit message.
Initial state:
$ ip nexthop list
id 200 via 2002:db8::2 dev bridge.10 scope link onlink
id 201 via 2002:db8::3 dev bridge scope link onlink
id 203 group 201/200
$ ip -6 route
2001:db8::10 nhid 203 metric 1024 pref medium
nexthop via 2002:db8::3 dev bridge weight 1 onlink
nexthop via 2002:db8::2 dev bridge.10 weight 1 onlink
Create rt6_info through one of the multipath legs, e.g.:
$ taskset -a -c 1 ./pkt_inj 24 bridge.10 2001:db8::10
(pkt_inj is just a custom packet generator, nothing special)
Then remove that leg from the group by replace (let's assume it is id
200 in this case):
$ ip nexthop replace id 203 group 201
Now remove the IPv6 route:
$ ip -6 route del 2001:db8::10/128
The route won't be really deleted due to the stale rt6_info holding 1
refcnt in nexthop id 200.
At this point we have the following reference count dependency:
(deleted) IPv6 route holds 1 reference over nhid 203
nh 203 holds 1 ref over id 201
nh 200 holds 1 ref over the net device and the route due to the stale
rt6_info
Now to create circular dependency between nh 200 and the IPv6 route, and
also to get a reference over nh 200, restore nhid 200 in the group:
$ ip nexthop replace id 203 group 201/200
And now we have a permanent circular dependncy because nhid 203 holds a
reference over nh 200 and 201, but the route holds a ref over nh 203 and
is deleted.
To trigger the bug just delete the group (nhid 203):
$ ip nexthop del id 203
It won't really be deleted due to the IPv6 route dependency, and now we
have 2 unlinked and deleted objects that reference each other: the group
and the IPv6 route. Since the group drops the reference it holds over its
entries at free time (i.e. its own refcount needs to drop to 0) that will
never happen and we get a permanent ref on them, since one of the entries
holds a reference over the IPv6 route it will also never be released.
At this point the dependencies are:
(deleted, only unlinked) IPv6 route holds reference over group nh 203
(deleted, only unlinked) group nh 203 holds reference over nh 201 and 200
nh 200 holds 1 ref over the net device and the route due to the stale
rt6_info
This is the last point where it can be fixed by running traffic through
nh 200, and specifically through the same CPU so the rt6_info (dst) will
get released due to the IPv6 genid, that in turn will free the IPv6
route, which in turn will free the ref count over the group nh 203.
If nh 200 is deleted at this point, it will never be released due to the
ref from the unlinked group 203, it will only be unlinked:
$ ip nexthop del id 200
$ ip nexthop
$
Now we can never release that stale rt6_info, we have IPv6 route with ref
over group nh 203, group nh 203 with ref over nh 200 and 201, nh 200 with
rt6_info (dst) with ref over the net device and the IPv6 route. All of
these objects are only unlinked, and cannot be released, thus they can't
release their ref counts.
Message from syslogd@dev at Nov 19 14:04:10 ...
kernel:[73501.828730] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
Message from syslogd@dev at Nov 19 14:04:20 ...
kernel:[73512.068811] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The new selftest runs a sequence which causes circular refcount
dependency between deleted objects which cannot be released and results
in a netdevice refcount imbalance.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When replacing a nexthop group, we must release the IPv6 per-cpu dsts of
the removed nexthop entries after an RCU grace period because they
contain references to the nexthop's net device and to the fib6 info.
With specific series of events[1] we can reach net device refcount
imbalance which is unrecoverable. IPv4 is not affected because dsts
don't take a refcount on the route.
[1]
$ ip nexthop list
id 200 via 2002:db8::2 dev bridge.10 scope link onlink
id 201 via 2002:db8::3 dev bridge scope link onlink
id 203 group 201/200
$ ip -6 route
2001:db8::10 nhid 203 metric 1024 pref medium
nexthop via 2002:db8::3 dev bridge weight 1 onlink
nexthop via 2002:db8::2 dev bridge.10 weight 1 onlink
Create rt6_info through one of the multipath legs, e.g.:
$ taskset -a -c 1 ./pkt_inj 24 bridge.10 2001:db8::10
(pkt_inj is just a custom packet generator, nothing special)
Then remove that leg from the group by replace (let's assume it is id
200 in this case):
$ ip nexthop replace id 203 group 201
Now remove the IPv6 route:
$ ip -6 route del 2001:db8::10/128
The route won't be really deleted due to the stale rt6_info holding 1
refcnt in nexthop id 200.
At this point we have the following reference count dependency:
(deleted) IPv6 route holds 1 reference over nhid 203
nh 203 holds 1 ref over id 201
nh 200 holds 1 ref over the net device and the route due to the stale
rt6_info
Now to create circular dependency between nh 200 and the IPv6 route, and
also to get a reference over nh 200, restore nhid 200 in the group:
$ ip nexthop replace id 203 group 201/200
And now we have a permanent circular dependncy because nhid 203 holds a
reference over nh 200 and 201, but the route holds a ref over nh 203 and
is deleted.
To trigger the bug just delete the group (nhid 203):
$ ip nexthop del id 203
It won't really be deleted due to the IPv6 route dependency, and now we
have 2 unlinked and deleted objects that reference each other: the group
and the IPv6 route. Since the group drops the reference it holds over its
entries at free time (i.e. its own refcount needs to drop to 0) that will
never happen and we get a permanent ref on them, since one of the entries
holds a reference over the IPv6 route it will also never be released.
At this point the dependencies are:
(deleted, only unlinked) IPv6 route holds reference over group nh 203
(deleted, only unlinked) group nh 203 holds reference over nh 201 and 200
nh 200 holds 1 ref over the net device and the route due to the stale
rt6_info
This is the last point where it can be fixed by running traffic through
nh 200, and specifically through the same CPU so the rt6_info (dst) will
get released due to the IPv6 genid, that in turn will free the IPv6
route, which in turn will free the ref count over the group nh 203.
If nh 200 is deleted at this point, it will never be released due to the
ref from the unlinked group 203, it will only be unlinked:
$ ip nexthop del id 200
$ ip nexthop
$
Now we can never release that stale rt6_info, we have IPv6 route with ref
over group nh 203, group nh 203 with ref over nh 200 and 201, nh 200 with
rt6_info (dst) with ref over the net device and the IPv6 route. All of
these objects are only unlinked, and cannot be released, thus they can't
release their ref counts.
Message from syslogd@dev at Nov 19 14:04:10 ...
kernel:[73501.828730] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
Message from syslogd@dev at Nov 19 14:04:20 ...
kernel:[73512.068811] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
Fixes: 7bf4796dd0 ("nexthops: add support for replace")
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need a way to release a fib6_nh's per-cpu dsts when replacing
nexthops otherwise we can end up with stale per-cpu dsts which hold net
device references, so add a new IPv6 stub called fib6_nh_release_dsts.
It must be used after an RCU grace period, so no new dsts can be created
through a group's nexthop entry.
Similar to fib6_nh_release it shouldn't be used if fib6_nh_init has failed
so it doesn't need a dummy stub when IPv6 is not enabled.
Fixes: 7bf4796dd0 ("nexthops: add support for replace")
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add entry for fsl,imx-audio-tlv320aic31xx audio codec. This codec is
configured to use BCLK as clock input.
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Link: https://lore.kernel.org/r/20211119153248.419802-6-ariel.dalessandro@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If BCLK is used as PLL input, the sysclk is determined by the hw
params. So it must be updated here to match the input frequency, based
on sample rate, format and channels.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Link: https://lore.kernel.org/r/20211119153248.419802-5-ariel.dalessandro@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add divisors for rates needed when the clk_in is set to BCLK.
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Link: https://lore.kernel.org/r/20211119153248.419802-4-ariel.dalessandro@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the clock used by the codec is BCLK, the operation parameters need
to be calculated from input sample rate and format. Low frequency rates
required different r multipliers, in order to achieve a higher PLL
output frequency.
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Link: https://lore.kernel.org/r/20211119153248.419802-3-ariel.dalessandro@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When a jack handler is registered in cs42l42_set_jack() the
initial state should be reported if an attached headphone/headset
has already been detected.
The jack detect sequence takes around 1 second: typically long
enough for the machine driver to probe and register the jack handler
in time to receive the first report from the interrupt handler. So
it is possible on some systems that the correct initial state was seen
simply because of lucky timing. Modular builds were more likely to
miss the reporting of the initial state.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 4ca239f337 ("ASoC: cs42l42: Always enable TS_PLUG and TS_UNPLUG interrupts")
Link: https://lore.kernel.org/r/20211119124854.58939-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are already 3 versions of the Up boards with support for the SOF
community key (ApolloLake, WhiskyLake, TigerLake). Rather than
continue to add quirks for each version, let's add a wildcard.
For WHL and TGL, the authentication supports both the SOF community
key and the firmware signed with the Intel production key. Given two
choices, the community key is the preferred option to allow developers
to sign their own firmware. The firmware signed with production key
can still be selected if needed with a kernel module
option (snd-sof-pci.fw_path="intel/sof")
Tested-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20211119231327.211946-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To keep the widget use_counts balanced, free the DAI widget
during suspend and also during the stop trigger.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-11-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for dynamic pipelines with multi-core
by using the platform-specific core_get/put() ops to
power up/down a core when a widget is set up/freed.
Along with this, a few redundant functions are removed:
1. sof_pipeline_core_enable() is no longer needed as the
pipeline core will be set up when the pipeline widget
is set up
2. sof_core_enable() is replaced with snd_sof_core_get()
4. core_power_up/down() DSP ops are deprecated and replaced with
core get/put ops.
5. Core power down in sof_widget_unload() during topology
removal is also removed as it is not really needed. For dynamic
pipelines, the cores will be powered off when they are not used.
For static pipelines, the cores will be powered off in the device
remove callback.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-10-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The core_power_up/down() ops will be deprecated. Use the
HDA platform-specific functions for powering up/down
the cores during probe/suspend/remove. The enabled_cores_mask
and the core ref_count's are manually updated in each of
these functions.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-9-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Free widgets for static pipelines in sof_tear_down_pipelines().
But this feature is unavailable in older firmware with ABI < 3.19.
Just reset widget use_count's for this case. This would ensure that
the secondary cores enabled required for topology setup are powered
down properly before the primary core is powered off during
system suspend.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-8-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the function sof_load_pipeline_ipc() and directly
send the IPC instead. The pipeline core is already enabled
with the call to sof_pipeline_core_enable() in sof_widget_setup().
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-7-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set core_get/put ops for CNL/ICL platforms. These platforms
do not support enabling/disabling secondary cores
dynamically. So skip sending the IPC to power off the
cores in the core_put op.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-6-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set core_get/put() ops for TGL. When core_get()
is requested for a core, its ref_count is incremented
and the PM_CORE_ENABLE IPC sent to the firmware to
power up the core if the current ref_count is 1.
Conversely, the ref_count is decremented in core_put()
and an IPC is sent to the DSP to power off the core
if the ref_count is 0.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-5-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add ops to get/put a core that will be used to power
up/down a core along with incrementing/decrementing
its ref_count.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-4-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add two fields num_cores and dsp_cores_ref_count to
struct snd_sof_dev. These will be used to maintain the
ref count for each core to determine when it should be
powered up or down.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119192621.4096077-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Resume common flow (System PM / Runtime PM) is like this:
sof_resume
-> specific device resume
-> snd_sof_load_firmware
-> snd_sof_dsp_reset (1)
-> load_modules()
-> snd_sof_run_firmware (2)
We need to implement dsp_reset callback (1) that will actually reset
the DSP but keep it stalled.
In order to implement this we do the following:
-> put DSP into reset (assert CoreReset bit from PWRCTL)
-> stall the DSP using RunStall bit from AudioDSP_REG2 mix
-> take DSP out of reset (de-assert CoreReset bit from PWRCTL)
At this moment the DSP is taken out of reset and Stalled! This means
that we can load the firmware and then start the DSP (2).
Until now we resetted the DSP by turning down the Audiomix PD. This
doesn't work for Runtime PM if another IP is keeping Audiomix PD up.
By introducing dsp_reset() we no longer rely on turning off the
audiomix to reset the DSP.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211119094319.81674-6-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On i.MX8M DSP is controlled via a set of registers
from Audio MIX. This patches gets a reference (via regmap)
to Audio Mix registers and implements DSP start.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211119094319.81674-5-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We make use of common imx8m_suspend / imx8m_resume functions
for both system PM and runtime PM.
imx8m_suspend:
- frees the MU channels
- disables the clocks
imx8m_resume
- enables the clocks
- requests the MU channels
On i.MX8MP there is no dedicated functionality to put the DSP in reset.
The only way of doing this is to POWER DOWN the Audiomix domain.
We are able to do this because turning off the clocks and freeing the
channels makes the Audiomix to have no users thus PM kernel core turns
it down.
SOF core will not call system PM suspend handler if the DSP is already
down, but at resume it will call the system PM resume. So, we need to
keep track of the state via snd_sof_dsp_set_power_state
Few insights on how SOF core handles the PM:
- SOF core uses PM runtime autosuspend (with a timeout of 2 secs)
- at probe, SOF core boots the DSP and lets the PM runtime suspend to
turn it off, if there is no activity
- when someone opens the ALSA sound card (aplay/arecord, etc) ALSA core
calls PM runtime resume to turn on the DSP
- when the ALSA sound card is closed SOF core make use of PM subsystem
to call PM runtime suspend and thus turning off the DSP.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211119094319.81674-4-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Handle clocks and mailbox channels at runtime suspend/resume
in order to save power.
DSP runtime PM uses a timeout of 2s. If device
is idle for 2s system will enter runtime suspend.
Because SOF state machine assumes that even if the DSP wasn't previously
active at a System resume, will re-load the firmware we need to make sure
that all needed resources are active.
Kernel core will take care of enabling the PD, we need to make sure that
we request the MU channels.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211119094319.81674-3-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
