From: Jim Quinlan <jim2101024@gmail.com> Date: 2021-03-12 20:46:53
v5 -- Improved (I hope) commit description (Bjorn).
-- Rnamed error labels (Krzyszt).
-- Fixed typos.
v4 -- does not rely on a pending commit, unlike v3.
v3 -- discard commit from v2; instead rely on the new function
reset_control_rearm provided in a recent commit [1] applied
to reset/next.
-- New commit to correct pcie-brcmstb.c usage of a reset controller
to use reset/rearm verses deassert/assert.
v2 -- refactor rescal-reset driver to implement assert/deassert rather than
reset because the reset call only fires once per lifetime and we need
to reset after every resume from S2 or S3.
-- Split the use of "ahci" and "rescal" controllers in separate fields
to keep things simple.
v1 -- original
Jim Quinlan (2):
ata: ahci_brcm: Fix use of BCM7216 reset controller
PCI: brcmstb: Use reset/rearm instead of deassert/assert
drivers/ata/ahci_brcm.c | 46 +++++++++++++--------------
drivers/pci/controller/pcie-brcmstb.c | 19 +++++++----
2 files changed, 36 insertions(+), 29 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Jim Quinlan <jim2101024@gmail.com> Date: 2021-03-12 20:47:25
The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device. Instead, we use reset/rearm. We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.
Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.
Fixes: 740d6c3708a9 ("PCI: brcmstb: Add control of rescal reset")
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pci/controller/pcie-brcmstb.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
@@ -1148,6 +1148,7 @@ static int brcm_pcie_suspend(struct device *dev)brcm_pcie_turn_off(pcie);ret=brcm_phy_stop(pcie);+reset_control_rearm(pcie->rescal);clk_disable_unprepare(pcie->clk);returnret;
@@ -1163,9 +1164,13 @@ static int brcm_pcie_resume(struct device *dev)base=pcie->base;clk_prepare_enable(pcie->clk);+ret=reset_control_reset(pcie->rescal);+if(ret)+gotoerr_disable_clk;+ret=brcm_phy_start(pcie);if(ret)-gotoerr;+gotoerr_reset;/* Take bridge out of reset so we can access the SERDES reg */pcie->bridge_sw_init_set(pcie,0);
@@ -1180,14 +1185,16 @@ static int brcm_pcie_resume(struct device *dev)ret=brcm_pcie_setup(pcie);if(ret)-gotoerr;+gotoerr_reset;if(pcie->msi)brcm_msi_set_regs(pcie->msi);return0;-err:+err_reset:+reset_control_rearm(pcie->rescal);+err_disable_clk:clk_disable_unprepare(pcie->clk);returnret;}
From: Lorenzo Pieralisi <hidden> Date: 2021-03-29 16:06:47
On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote:
The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device. Instead, we use reset/rearm. We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.
Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.
Fixes: 740d6c3708a9 ("PCI: brcmstb: Add control of rescal reset")
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pci/controller/pcie-brcmstb.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
Should I take this patch in the PCI queue ?
Thanks,
Lorenzo
@@ -1148,6 +1148,7 @@ static int brcm_pcie_suspend(struct device *dev)brcm_pcie_turn_off(pcie);ret=brcm_phy_stop(pcie);+reset_control_rearm(pcie->rescal);clk_disable_unprepare(pcie->clk);returnret;
@@ -1163,9 +1164,13 @@ static int brcm_pcie_resume(struct device *dev)base=pcie->base;clk_prepare_enable(pcie->clk);+ret=reset_control_reset(pcie->rescal);+if(ret)+gotoerr_disable_clk;+ret=brcm_phy_start(pcie);if(ret)-gotoerr;+gotoerr_reset;/* Take bridge out of reset so we can access the SERDES reg */pcie->bridge_sw_init_set(pcie,0);
@@ -1180,14 +1185,16 @@ static int brcm_pcie_resume(struct device *dev)ret=brcm_pcie_setup(pcie);if(ret)-gotoerr;+gotoerr_reset;if(pcie->msi)brcm_msi_set_regs(pcie->msi);return0;-err:+err_reset:+reset_control_rearm(pcie->rescal);+err_disable_clk:clk_disable_unprepare(pcie->clk);returnret;}
From: Lorenzo Pieralisi <hidden> Date: 2021-03-29 16:11:45
On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote:
The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device. Instead, we use reset/rearm. We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.
Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.
Actually - I am sorry but it looks like you will have to split the patch
in two since this is two logical changes.
Thanks,
Lorenzo
quoted hunk
Fixes: 740d6c3708a9 ("PCI: brcmstb: Add control of rescal reset")
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pci/controller/pcie-brcmstb.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
@@ -1148,6 +1148,7 @@ static int brcm_pcie_suspend(struct device *dev)brcm_pcie_turn_off(pcie);ret=brcm_phy_stop(pcie);+reset_control_rearm(pcie->rescal);clk_disable_unprepare(pcie->clk);returnret;
@@ -1163,9 +1164,13 @@ static int brcm_pcie_resume(struct device *dev)base=pcie->base;clk_prepare_enable(pcie->clk);+ret=reset_control_reset(pcie->rescal);+if(ret)+gotoerr_disable_clk;+ret=brcm_phy_start(pcie);if(ret)-gotoerr;+gotoerr_reset;/* Take bridge out of reset so we can access the SERDES reg */pcie->bridge_sw_init_set(pcie,0);
@@ -1180,14 +1185,16 @@ static int brcm_pcie_resume(struct device *dev)ret=brcm_pcie_setup(pcie);if(ret)-gotoerr;+gotoerr_reset;if(pcie->msi)brcm_msi_set_regs(pcie->msi);return0;-err:+err_reset:+reset_control_rearm(pcie->rescal);+err_disable_clk:clk_disable_unprepare(pcie->clk);returnret;}
On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote:
quoted
The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device. Instead, we use reset/rearm. We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.
Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.
Actually - I am sorry but it looks like you will have to split the patch
in two since this is two logical changes.
I do not believe this can be easily split, since there is currently a
misused of the reset controller API and this patch fixes all call sites
at once. It would not really make sense to fix probe/remove and then
leave suspend/resume broken in the same manner.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lorenzo Pieralisi <hidden> Date: 2021-03-29 16:59:55
On Mon, Mar 29, 2021 at 09:50:13AM -0700, Florian Fainelli wrote:
On 3/29/21 9:10 AM, Lorenzo Pieralisi wrote:
quoted
On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote:
quoted
The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device. Instead, we use reset/rearm. We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.
Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.
Actually - I am sorry but it looks like you will have to split the patch
in two since this is two logical changes.
I do not believe this can be easily split, since there is currently a
misused of the reset controller API and this patch fixes all call sites
at once. It would not really make sense to fix probe/remove and then
leave suspend/resume broken in the same manner.
Right - I was reading the previous versions of the set, it makes sense
to keep it in one logical change.
Do you want me to take it or you prefer an ACK so that it can go via
a different tree ?
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Mar 29, 2021 at 09:50:13AM -0700, Florian Fainelli wrote:
quoted
On 3/29/21 9:10 AM, Lorenzo Pieralisi wrote:
quoted
On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote:
quoted
The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device. Instead, we use reset/rearm. We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.
Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.
Actually - I am sorry but it looks like you will have to split the patch
in two since this is two logical changes.
I do not believe this can be easily split, since there is currently a
misused of the reset controller API and this patch fixes all call sites
at once. It would not really make sense to fix probe/remove and then
leave suspend/resume broken in the same manner.
Right - I was reading the previous versions of the set, it makes sense
to keep it in one logical change.
Do you want me to take it or you prefer an ACK so that it can go via
a different tree ?
I would be comfortable with you taking this via the PCI driver trees, we
would want an Ack from Jens that he is okay with taking the ahci_brcm.c
change as well through your tree.
Thank you!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lorenzo Pieralisi <hidden> Date: 2021-04-06 15:42:27
On Fri, 12 Mar 2021 15:45:53 -0500, Jim Quinlan wrote:
v5 -- Improved (I hope) commit description (Bjorn).
-- Rnamed error labels (Krzyszt).
-- Fixed typos.
v4 -- does not rely on a pending commit, unlike v3.
v3 -- discard commit from v2; instead rely on the new function
reset_control_rearm provided in a recent commit [1] applied
to reset/next.
-- New commit to correct pcie-brcmstb.c usage of a reset controller
to use reset/rearm verses deassert/assert.
[...]
On Fri, 12 Mar 2021 15:45:53 -0500, Jim Quinlan wrote:
quoted
v5 -- Improved (I hope) commit description (Bjorn).
-- Rnamed error labels (Krzyszt).
-- Fixed typos.
v4 -- does not rely on a pending commit, unlike v3.
v3 -- discard commit from v2; instead rely on the new function
reset_control_rearm provided in a recent commit [1] applied
to reset/next.
-- New commit to correct pcie-brcmstb.c usage of a reset controller
to use reset/rearm verses deassert/assert.
[...]