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
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
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
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
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
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
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
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
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.
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.
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
>
> ---
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
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
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
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
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
16 matches
Mail list logo