Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-13 Thread Asutosh Das (asd)

Vivek,

On 8/11/2017 12:42 PM, Vivek Gautam wrote:

On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
 wrote:


Vivek,


Can you kindly review this patch series (for UFS controller changes)
and consider giving your Ack so that Kishon can pull in the series
through phy tree.


SCSI piece looks OK.


Thank you Martin for your review.


Would still like Subhash to review the rest.


Subhash is on vacation with limited access to emails. I will ask
his team to take a look.


Looks good to me.

regards
Vivek



--
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
Asutosh Das (asd)
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project


Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-11 Thread Vivek Gautam
On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
 wrote:
>
> Vivek,
>
>> Can you kindly review this patch series (for UFS controller changes)
>> and consider giving your Ack so that Kishon can pull in the series
>> through phy tree.
>
> SCSI piece looks OK.

Thank you Martin for your review.
>
> Would still like Subhash to review the rest.

Subhash is on vacation with limited access to emails. I will ask
his team to take a look.

regards
Vivek

>
> --
> Martin K. Petersen  Oracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-10 Thread Martin K. Petersen

Vivek,

> Can you kindly review this patch series (for UFS controller changes)
> and consider giving your Ack so that Kishon can pull in the series
> through phy tree.

SCSI piece looks OK.

Would still like Subhash to review the rest.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-08 Thread Vivek Gautam
Hi Martin, Subhash


On Wed, Aug 9, 2017 at 11:18 AM, Kishon Vijay Abraham I  wrote:
> Vivek,
>
> On Tuesday 08 August 2017 09:20 PM, Vivek Gautam wrote:
>> Hi Koshon,
>>
>> On 2017-08-08 17:39, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote:
 Refactoring the qcom-ufs phy and host controller code to move
 further towards the generic phy usage. Right now the qcom-ufs exports
 a bunch of APIs that are used by the host controller to initialize
 the phy.
 With this patch series, we populate the phy_init() which was a no-op
 earlier. The host controller then calls the phy_init() at the designated
 place rather than doing it invariably in ufs_hcd_init().

 As part of this series, we introduce phy modes for ufs phy.
 The M-PHY has two data rates defined for each generations (Gears) -
 Rate A and Rate B. These can serve as the two modes of ufs HS phy.
 Host controller can direct the phy to set the respective configurations
 based on the phy modes.

 The patch-series has been tested with necessary dt patches on db820c.
>>>
>>> Can the first 3 patches go independently of the other 2 or should all this 
>>> be
>>> merged together?
>>
>> The first 3 patches are independent, but the next 2 patches depend on those 3
>> for functionality.
>> I would prefer all to go in one tree. If you want to pull these in the phy 
>> tree,
>> I will request Subhash/Martin to ack the patches.

Can you kindly review this patch series (for UFS controller changes) and
consider giving your Ack so that Kishon can pull in the series through phy tree.
Thanks.

best regards
Vivek

>
> sure, that should be fine!
>
> Thanks
> Kishon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-08 Thread Kishon Vijay Abraham I
Vivek,

On Tuesday 08 August 2017 09:20 PM, Vivek Gautam wrote:
> Hi Koshon,
> 
> On 2017-08-08 17:39, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote:
>>> Refactoring the qcom-ufs phy and host controller code to move
>>> further towards the generic phy usage. Right now the qcom-ufs exports
>>> a bunch of APIs that are used by the host controller to initialize
>>> the phy.
>>> With this patch series, we populate the phy_init() which was a no-op
>>> earlier. The host controller then calls the phy_init() at the designated
>>> place rather than doing it invariably in ufs_hcd_init().
>>>
>>> As part of this series, we introduce phy modes for ufs phy.
>>> The M-PHY has two data rates defined for each generations (Gears) -
>>> Rate A and Rate B. These can serve as the two modes of ufs HS phy.
>>> Host controller can direct the phy to set the respective configurations
>>> based on the phy modes.
>>>
>>> The patch-series has been tested with necessary dt patches on db820c.
>>
>> Can the first 3 patches go independently of the other 2 or should all this be
>> merged together?
> 
> The first 3 patches are independent, but the next 2 patches depend on those 3
> for functionality.
> I would prefer all to go in one tree. If you want to pull these in the phy 
> tree,
> I will request Subhash/Martin to ack the patches.

sure, that should be fine!

Thanks
Kishon


Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-08 Thread Vivek Gautam

Hi Koshon,

On 2017-08-08 17:39, Kishon Vijay Abraham I wrote:

Hi,

On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote:

Refactoring the qcom-ufs phy and host controller code to move
further towards the generic phy usage. Right now the qcom-ufs exports
a bunch of APIs that are used by the host controller to initialize
the phy.
With this patch series, we populate the phy_init() which was a no-op
earlier. The host controller then calls the phy_init() at the 
designated

place rather than doing it invariably in ufs_hcd_init().

As part of this series, we introduce phy modes for ufs phy.
The M-PHY has two data rates defined for each generations (Gears) -
Rate A and Rate B. These can serve as the two modes of ufs HS phy.
Host controller can direct the phy to set the respective 
configurations

based on the phy modes.

The patch-series has been tested with necessary dt patches on db820c.


Can the first 3 patches go independently of the other 2 or should all 
this be

merged together?


The first 3 patches are independent, but the next 2 patches depend on 
those 3 for functionality.
I would prefer all to go in one tree. If you want to pull these in the 
phy tree,

I will request Subhash/Martin to ack the patches.


Regards
Vivek



Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-08 Thread Kishon Vijay Abraham I
Hi,

On Friday 04 August 2017 12:18 PM, Vivek Gautam wrote:
> Refactoring the qcom-ufs phy and host controller code to move
> further towards the generic phy usage. Right now the qcom-ufs exports
> a bunch of APIs that are used by the host controller to initialize
> the phy.
> With this patch series, we populate the phy_init() which was a no-op
> earlier. The host controller then calls the phy_init() at the designated
> place rather than doing it invariably in ufs_hcd_init().
> 
> As part of this series, we introduce phy modes for ufs phy.
> The M-PHY has two data rates defined for each generations (Gears) -
> Rate A and Rate B. These can serve as the two modes of ufs HS phy.
> Host controller can direct the phy to set the respective configurations
> based on the phy modes.
> 
> The patch-series has been tested with necessary dt patches on db820c.

Can the first 3 patches go independently of the other 2 or should all this be
merged together?

Thanks
Kishon


[PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

2017-08-03 Thread Vivek Gautam
Refactoring the qcom-ufs phy and host controller code to move
further towards the generic phy usage. Right now the qcom-ufs exports
a bunch of APIs that are used by the host controller to initialize
the phy.
With this patch series, we populate the phy_init() which was a no-op
earlier. The host controller then calls the phy_init() at the designated
place rather than doing it invariably in ufs_hcd_init().

As part of this series, we introduce phy modes for ufs phy.
The M-PHY has two data rates defined for each generations (Gears) -
Rate A and Rate B. These can serve as the two modes of ufs HS phy.
Host controller can direct the phy to set the respective configurations
based on the phy modes.

The patch-series has been tested with necessary dt patches on db820c.

Vivek Gautam (5):
  dt-bindings: phy: Add PHY_TYPE_UFS definition
  phy: Add UFS PHY modes
  phy: qcom-ufs: Add support to set phy mode
  scsi/ufs: qcom: Set phy mode based on the controllers HS MODE
  ufs/phy: qcom: Refactor to use phy_init call

 drivers/phy/qualcomm/phy-qcom-ufs-i.h|  4 +--
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c | 23 ++--
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c | 23 ++--
 drivers/phy/qualcomm/phy-qcom-ufs.c  | 38 +++
 drivers/scsi/ufs/ufs-qcom.c  | 39 
 include/dt-bindings/phy/phy.h|  1 +
 include/linux/phy/phy-qcom-ufs.h |  3 ---
 include/linux/phy/phy.h  |  2 ++
 8 files changed, 74 insertions(+), 59 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation