| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354 |
- From 72bc31aa621e21a7c36a7da8aa6f6a77bb234e0b Mon Sep 17 00:00:00 2001
- From: Stephan Gerhold <[email protected]>
- Date: Wed, 6 Jul 2022 15:41:29 +0200
- Subject: [PATCH] clk: qcom: reset: Allow specifying custom reset delay
- The amount of time required between asserting and deasserting the reset
- signal can vary depending on the involved hardware component. Sometimes
- 1 us might not be enough and a larger delay is necessary to conform to
- the specifications.
- Usually this is worked around in the consuming drivers, by replacing
- reset_control_reset() with a sequence of reset_control_assert(), waiting
- for a custom delay, followed by reset_control_deassert().
- However, in some cases the driver making use of the reset is generic and
- can be used with different reset controllers. In this case the reset
- time requirement is better handled directly by the reset controller
- driver.
- Make this possible by adding an "udelay" field to the qcom_reset_map
- that allows setting a different reset delay (in microseconds).
- Signed-off-by: Stephan Gerhold <[email protected]>
- Signed-off-by: Bjorn Andersson <[email protected]>
- Link: https://lore.kernel.org/r/[email protected]
- ---
- drivers/clk/qcom/reset.c | 4 +++-
- drivers/clk/qcom/reset.h | 1 +
- 2 files changed, 4 insertions(+), 1 deletion(-)
- --- a/drivers/clk/qcom/reset.c
- +++ b/drivers/clk/qcom/reset.c
- @@ -13,8 +13,10 @@
-
- static int qcom_reset(struct reset_controller_dev *rcdev, unsigned long id)
- {
- + struct qcom_reset_controller *rst = to_qcom_reset_controller(rcdev);
- +
- rcdev->ops->assert(rcdev, id);
- - udelay(1);
- + udelay(rst->reset_map[id].udelay ?: 1); /* use 1 us as default */
- rcdev->ops->deassert(rcdev, id);
- return 0;
- }
- --- a/drivers/clk/qcom/reset.h
- +++ b/drivers/clk/qcom/reset.h
- @@ -11,6 +11,7 @@
- struct qcom_reset_map {
- unsigned int reg;
- u8 bit;
- + u8 udelay;
- };
-
- struct regmap;
|