Re: [PATCH v1 2/2] phy: update obsolete configuration of ARCH_MSM into ARCH_QCOM

2015-05-11 Thread Stephen Boyd
On 05/11/15 08:15, Yaniv Gardi wrote: > Since ARCH_MSM is no longer supported as configuration definition, > it should be modified into ARCH_QCOM in order to add support for > Qualcomm platforms. > > Signed-off-by: Yaniv Gardi > > --- I've already sent this patch[1]. Can you please ack it? [1] h

Re: [PATCH v2 01/10] phy: qcom-ufs: remove failure when rx/tx_iface_clk are absent

2016-10-18 Thread Stephen Boyd
On 10/18/2016 07:28 AM, Vivek Gautam wrote: > From: Yaniv Gardi > > Since in future UFS Phy's the tx_iface_clk and rx_iface_clk > are no longer exist, we should not fail when their initialization > fail, but rather just report with debug message. > > Signed-off-by: Yaniv Gardi > Signed-off-by: Vi

[PATCH] ufs-qcom: Switch dependency to ARCH_QCOM

2015-04-10 Thread Stephen Boyd
This device only exists on platforms under ARCH_QCOM, not ARCH_MSM. Cc: Yaniv Gardi Cc: Dov Levenglick Cc: Vinayak Holikatti Cc: David Brown Cc: Bryan Huntsman Cc: Daniel Walker Signed-off-by: Stephen Boyd --- drivers/scsi/ufs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH v2 17/17] scsi: ufs-qcom: fix compilation warnings

2015-10-26 Thread Stephen Boyd
On 10/26/2015 08:41 AM, Yaniv Gardi wrote: > Tnis patch fixes the following compilation warnings: > ...ufs-qcom.c:1201:40: > warning: incorrect type in argument 1 (different address spaces) > ...ufs-qcom.c:1201:40: > expected void const *ptr > ...ufs-qcom.c:1201:40: > got void [no

Re: [PATCH v2 17/17] scsi: ufs-qcom: fix compilation warnings

2015-10-27 Thread Stephen Boyd
On 10/27/2015 03:10 AM, yga...@codeaurora.org wrote: >> On 10/26/2015 08:41 AM, Yaniv Gardi wrote: >>> Tnis patch fixes the following compilation warnings: >>> ...ufs-qcom.c:1201:40: >>> warning: incorrect type in argument 1 (different address spaces) >>> ...ufs-qcom.c:1201:40: >>> expected

Re: [PATCH v2 17/17] scsi: ufs-qcom: fix compilation warnings

2015-10-27 Thread Stephen Boyd
On 10/27/2015 11:22 AM, yga...@codeaurora.org wrote: >> On 10/27/2015 03:10 AM, yga...@codeaurora.org wrote: On 10/26/2015 08:41 AM, Yaniv Gardi wrote: > Tnis patch fixes the following compilation warnings: > ...ufs-qcom.c:1201:40: > warning: incorrect type in argument 1 (differe

Re: [PATCH v1 0/8] phy: qcom-ufs: Enable regulators to be off in suspend

2019-01-16 Thread Stephen Boyd
Quoting Evan Green (2019-01-11 15:01:21) > > Because the UFS PHY reset bit is now toggled in the PHY, rather > than in ufs-qcom, this also percolated to all other PHYs using > ufs-qcom, which from what I can see is just 8996. > > There are a couple of tradeoffs in this series that I'd welcome fee

Re: [PATCH v1 5/8] scsi: ufs: qcom: Expose the reset controller for PHY

2019-01-18 Thread Stephen Boyd
Quoting Evan Green (2019-01-11 15:01:26) > diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c > index 3aeadb14aae1e..db46f9a64b54c 100644 > --- a/drivers/scsi/ufs/ufs-qcom.c > +++ b/drivers/scsi/ufs/ufs-qcom.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#includ

Re: [PATCH v2 6/9] scsi: ufs: qcom: Expose the reset controller for PHY

2019-02-01 Thread Stephen Boyd
Quoting Evan Green (2019-01-23 14:11:34) > Expose a reset controller that the phy can use to perform its > initialization in a single callback. > > Also, change the use of the phy functions from ufs-qcom such that > phy_poweron actually fires up the phy, and phy_poweroff actually > powers it down.

RE: [PATCH v3 6/8] scsi: ufs: qcom: Expose the reset controller for PHY

2019-02-06 Thread Stephen Boyd
Quoting Avri Altman (2019-02-06 05:57:17) > Hi, > > > On 06/02/19 12:29 AM, Evan Green wrote: > > > Expose a reset controller that the phy will later use to control its > > > own PHY reset in the UFS controller. This will enable the combining > > > of PHY init functionality into a single function.

Re: [PATCH v3 6/8] scsi: ufs: qcom: Expose the reset controller for PHY

2019-02-06 Thread Stephen Boyd
Quoting Evan Green (2019-02-05 10:59:00) > Expose a reset controller that the phy will later use to control its > own PHY reset in the UFS controller. This will enable the combining > of PHY init functionality into a single function. > > Signed-off-by: Evan Green > > ---

Re: [PATCH v3 7/8] phy: qcom: Utilize UFS reset controller

2019-02-06 Thread Stephen Boyd
Quoting Evan Green (2019-02-05 10:59:01) > diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c > b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c > index aef40f7a41d4..b05f89d734f0 100644 > --- a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c > +++ b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c

Re: [PATCH v3 8/8] phy: ufs-qcom: Refactor all init steps into phy_poweron

2019-02-06 Thread Stephen Boyd
as the generic PHY code does the reference counting. The > 14/20nm-specific init functions get collapsed into the generic power_on() > function, with the addition of a calibrate() callback specific to 14/20nm. > > Signed-off-by: Evan Green Reviewed-by: Stephen Boyd although it may ch

Re: [PATCH v4 7/8] phy: qcom: Utilize UFS reset controller

2019-02-22 Thread Stephen Boyd
Quoting Evan Green (2019-02-13 15:25:25) > Move the PHY reset from ufs-qcom into the respective PHYs. This will > allow us to merge the two phases of UFS PHY initialization. > > Signed-off-by: Evan Green > > --- Reviewed-by: Stephen Boyd

Re: [PATCH v4 8/8] phy: ufs-qcom: Refactor all init steps into phy_poweron

2019-02-22 Thread Stephen Boyd
as the generic PHY code does the reference counting. The > 14/20nm-specific init functions get collapsed into the generic power_on() > function, with the addition of a calibrate() callback specific to 14/20nm. > > Signed-off-by: Evan Green > --- Reviewed-by: Stephen Boyd

Re: [PATCH] scsi: ufs: Schedule clk gating work on correct queue

2018-10-17 Thread Stephen Boyd
om_fork+0x10/0x18 > > The simple solution is to put the gate_work on the same WQ_MEM_RECLAIM > work queue as the ungate_work. > > Fixes: 10e5e37581fc ("scsi: ufs: Add clock ungating to a separate workqueue") > Signed-off-by: Evan Green > > --- Reviewed-by: Stephen Boyd