diff options
author | Serge Semin <Sergey.Semin@baikalelectronics.ru> | 2022-09-09 22:36:08 +0300 |
---|---|---|
committer | Damien Le Moal <damien.lemoal@opensource.wdc.com> | 2022-09-17 01:39:34 +0900 |
commit | f67f12ff57bcfcd7d64280f748787793217faeaf (patch) | |
tree | 3514925a9eef7ed8b16e579a40c90dba044ff384 /drivers/ata/ahci.h | |
parent | 3f74cd046fbed349be977606f938e6429155e7b5 (diff) | |
download | linux-f67f12ff57bcfcd7d64280f748787793217faeaf.tar.gz linux-f67f12ff57bcfcd7d64280f748787793217faeaf.tar.bz2 linux-f67f12ff57bcfcd7d64280f748787793217faeaf.zip |
ata: libahci_platform: Introduce reset assertion/deassertion methods
Currently the ACHI-platform library supports only the assert and deassert
reset signals and ignores the platforms with self-deasserting reset lines.
That prone to having the platforms with self-deasserting reset method
misbehaviour when it comes to resuming from sleep state after the clocks
have been fully disabled. For such cases the controller needs to be fully
reset all over after the reference clocks are enabled and stable,
otherwise the controller state machine might be in an undetermined state.
The best solution would be to auto-detect which reset method is supported
by the particular platform and use it implicitly in the framework of the
ahci_platform_enable_resources()/ahci_platform_disable_resources()
methods. Alas it can't be implemented due to the AHCI-platform library
already supporting the shared reset control lines. As [1] says in such
case we have to use only one of the next methods:
+ reset_control_assert()/reset_control_deassert();
+ reset_control_reset()/reset_control_rearm().
If the driver had an exclusive control over the reset lines we could have
been able to manipulate the lines with no much limitation and just used
the combination of the methods above to cover all the possible
reset-control cases. Since the shared reset control has already been
advertised and couldn't be changed with no risk to breaking the platforms
relying on it, we have no choice but to make the platform drivers to
determine which reset methods the platform reset system supports.
In order to implement both types of reset control support we suggest to
introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which
when passed to the ahci_platform_get_resources() method together with the
AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are
self-deasserting thus the reset_control_reset()/reset_control_rearm() will
be used to control the reset state. Otherwise the
reset_control_deassert()/reset_control_assert() methods will be utilized.
[1] Documentation/driver-api/reset.rst
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Diffstat (limited to 'drivers/ata/ahci.h')
-rw-r--r-- | drivers/ata/ahci.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h index c3770a19781b..7d834deefeb9 100644 --- a/drivers/ata/ahci.h +++ b/drivers/ata/ahci.h @@ -340,6 +340,7 @@ struct ahci_host_priv { bool got_runtime_pm; /* Did we do pm_runtime_get? */ unsigned int n_clks; struct clk_bulk_data *clks; /* Optional */ + unsigned int f_rsts; struct reset_control *rsts; /* Optional */ struct regulator **target_pwrs; /* Optional */ struct regulator *ahci_regulator;/* Optional */ |