diff mbox

[1/2] phy-rockchip-pcie: add set_mode callback

Message ID 1497601068-181656-1-git-send-email-shawn.lin@rock-chips.com (mailing list archive)
State New, archived
Headers show

Commit Message

Shawn Lin June 16, 2017, 8:17 a.m. UTC
phy_mode was added for switching USB mode purposely as
well as phy_set_mode API. However other types of PHY could
also have some miscellaneous setting/modes need to be
handled. This patch is gonna support this callback for
phy-rockchip-pcie and do some power-saving work there.
Note that we just stuff in some other values other that the
existing phy_mode and convert it in the coressponding driver
instead, otherwise we should extend the phy_mode again which
it doesn't make sense to add in new driver's specificed value.
Overall it looks fine to me as the controller's driver and the
phy's driver are paired so that the caller and the consumer should
be able to keep the value(mode) in consistent.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---

 drivers/phy/rockchip/phy-rockchip-pcie.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Comments

Shawn Lin July 5, 2017, 7:18 a.m. UTC | #1
Hi Kishon,

On 2017/6/16 16:17, Shawn Lin wrote:
> phy_mode was added for switching USB mode purposely as
> well as phy_set_mode API. However other types of PHY could
> also have some miscellaneous setting/modes need to be
> handled. This patch is gonna support this callback for
> phy-rockchip-pcie and do some power-saving work there.
> Note that we just stuff in some other values other that the
> existing phy_mode and convert it in the coressponding driver
> instead, otherwise we should extend the phy_mode again which
> it doesn't make sense to add in new driver's specificed value.
> Overall it looks fine to me as the controller's driver and the
> phy's driver are paired so that the caller and the consumer should
> be able to keep the value(mode) in consistent.
> 

Any chance for you to have a look at this patch? :)

> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> 
>   drivers/phy/rockchip/phy-rockchip-pcie.c | 22 ++++++++++++++++++++++
>   1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-pcie.c b/drivers/phy/rockchip/phy-rockchip-pcie.c
> index 6904633..9ffad15 100644
> --- a/drivers/phy/rockchip/phy-rockchip-pcie.c
> +++ b/drivers/phy/rockchip/phy-rockchip-pcie.c
> @@ -255,11 +255,33 @@ static int rockchip_pcie_phy_exit(struct phy *phy)
>   	return 0;
>   }
>   
> +static int rockchip_pcie_phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> +	struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
> +	u8 map = (u8)mode;
> +	int i;
> +
> +	for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
> +		if (map & BIT(i))
> +			continue;
> +
> +		dev_dbg(&phy->dev, "idling lane %d\n", i);
> +		regmap_write(rk_phy->reg_base,
> +			     rk_phy->phy_data->pcie_laneoff,
> +			     HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
> +			     PHY_LANE_IDLE_MASK,
> +			     PHY_LANE_IDLE_A_SHIFT + i));
> +	}
> +
> +	return 0;
> +}
> +
>   static const struct phy_ops ops = {
>   	.init		= rockchip_pcie_phy_init,
>   	.exit		= rockchip_pcie_phy_exit,
>   	.power_on	= rockchip_pcie_phy_power_on,
>   	.power_off	= rockchip_pcie_phy_power_off,
> +	.set_mode	= rockchip_pcie_phy_set_mode,
>   	.owner		= THIS_MODULE,
>   };
>   
>
Bjorn Helgaas July 10, 2017, 8:39 p.m. UTC | #2
On Fri, Jun 16, 2017 at 04:17:47PM +0800, Shawn Lin wrote:
> phy_mode was added for switching USB mode purposely as
> well as phy_set_mode API. However other types of PHY could
> also have some miscellaneous setting/modes need to be
> handled. This patch is gonna support this callback for
> phy-rockchip-pcie and do some power-saving work there.

> Note that we just stuff in some other values other that the
> existing phy_mode and convert it in the coressponding driver
> instead, otherwise we should extend the phy_mode again which
> it doesn't make sense to add in new driver's specificed value.
> Overall it looks fine to me as the controller's driver and the
> phy's driver are paired so that the caller and the consumer should
> be able to keep the value(mode) in consistent.

s/coressponding/corresponding/
s/specificed/specified/
s/in consistent/consistent/

> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> 
>  drivers/phy/rockchip/phy-rockchip-pcie.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-pcie.c b/drivers/phy/rockchip/phy-rockchip-pcie.c
> index 6904633..9ffad15 100644
> --- a/drivers/phy/rockchip/phy-rockchip-pcie.c
> +++ b/drivers/phy/rockchip/phy-rockchip-pcie.c
> @@ -255,11 +255,33 @@ static int rockchip_pcie_phy_exit(struct phy *phy)
>  	return 0;
>  }
>  
> +static int rockchip_pcie_phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> +	struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
> +	u8 map = (u8)mode;
> +	int i;
> +
> +	for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
> +		if (map & BIT(i))
> +			continue;

phy_mode is defined as:

  enum phy_mode {
	  PHY_MODE_INVALID,
	  PHY_MODE_USB_HOST,
	  PHY_MODE_USB_DEVICE,
	  PHY_MODE_USB_OTG,
  };

You're using phy_mode as something entirely different -- a bitmap of
which lanes you want to keep active.  I understand you're trying to
avoid extending phy_mode again, but I just want to point out that
there are no other places that subvert phy_mode as you're doing.

It's probably worth a comment here about why we're not using the
standard enum values.  I see you already have one at the caller.

I'm not the PHY guy, so I'd like Kishon's ack before going down this
road.

> +
> +		dev_dbg(&phy->dev, "idling lane %d\n", i);
> +		regmap_write(rk_phy->reg_base,
> +			     rk_phy->phy_data->pcie_laneoff,
> +			     HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
> +			     PHY_LANE_IDLE_MASK,
> +			     PHY_LANE_IDLE_A_SHIFT + i));
> +	}
> +
> +	return 0;
> +}
> +
>  static const struct phy_ops ops = {
>  	.init		= rockchip_pcie_phy_init,
>  	.exit		= rockchip_pcie_phy_exit,
>  	.power_on	= rockchip_pcie_phy_power_on,
>  	.power_off	= rockchip_pcie_phy_power_off,
> +	.set_mode	= rockchip_pcie_phy_set_mode,
>  	.owner		= THIS_MODULE,
>  };
>  
> -- 
> 1.9.1
> 
>
Kishon Vijay Abraham I July 11, 2017, 4:45 a.m. UTC | #3
Hi,

On Friday 16 June 2017 01:47 PM, Shawn Lin wrote:
> phy_mode was added for switching USB mode purposely as
> well as phy_set_mode API. However other types of PHY could
> also have some miscellaneous setting/modes need to be
> handled. This patch is gonna support this callback for
> phy-rockchip-pcie and do some power-saving work there.
> Note that we just stuff in some other values other that the
> existing phy_mode and convert it in the coressponding driver
> instead, otherwise we should extend the phy_mode again which
> it doesn't make sense to add in new driver's specificed value.
> Overall it looks fine to me as the controller's driver and the
> phy's driver are paired so that the caller and the consumer should
> be able to keep the value(mode) in consistent.

I really don't prefer using an API other that what it is intended for. We have
to come up with a better way for handling this.

IIUC this patch sets unused lanes in idle mode? If yes, then can't we model
each lane as a separate phy, so that we can power-on/power-off each lane
independently.

Thanks
Kishon
> 
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> 
>  drivers/phy/rockchip/phy-rockchip-pcie.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-pcie.c b/drivers/phy/rockchip/phy-rockchip-pcie.c
> index 6904633..9ffad15 100644
> --- a/drivers/phy/rockchip/phy-rockchip-pcie.c
> +++ b/drivers/phy/rockchip/phy-rockchip-pcie.c
> @@ -255,11 +255,33 @@ static int rockchip_pcie_phy_exit(struct phy *phy)
>  	return 0;
>  }
>  
> +static int rockchip_pcie_phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> +	struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
> +	u8 map = (u8)mode;
> +	int i;
> +
> +	for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
> +		if (map & BIT(i))
> +			continue;
> +
> +		dev_dbg(&phy->dev, "idling lane %d\n", i);
> +		regmap_write(rk_phy->reg_base,
> +			     rk_phy->phy_data->pcie_laneoff,
> +			     HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
> +			     PHY_LANE_IDLE_MASK,
> +			     PHY_LANE_IDLE_A_SHIFT + i));
> +	}
> +
> +	return 0;
> +}
> +
>  static const struct phy_ops ops = {
>  	.init		= rockchip_pcie_phy_init,
>  	.exit		= rockchip_pcie_phy_exit,
>  	.power_on	= rockchip_pcie_phy_power_on,
>  	.power_off	= rockchip_pcie_phy_power_off,
> +	.set_mode	= rockchip_pcie_phy_set_mode,
>  	.owner		= THIS_MODULE,
>  };
>  
>
Brian Norris July 11, 2017, 5:20 a.m. UTC | #4
Hi Kishon,

On Mon, Jul 10, 2017 at 9:45 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> On Friday 16 June 2017 01:47 PM, Shawn Lin wrote:
> > phy_mode was added for switching USB mode purposely as
> > well as phy_set_mode API. However other types of PHY could
> > also have some miscellaneous setting/modes need to be
> > handled. This patch is gonna support this callback for
> > phy-rockchip-pcie and do some power-saving work there.
> > Note that we just stuff in some other values other that the
> > existing phy_mode and convert it in the coressponding driver
> > instead, otherwise we should extend the phy_mode again which
> > it doesn't make sense to add in new driver's specificed value.
> > Overall it looks fine to me as the controller's driver and the
> > phy's driver are paired so that the caller and the consumer should
> > be able to keep the value(mode) in consistent.
>
> I really don't prefer using an API other that what it is intended for. We have
> to come up with a better way for handling this.
>
> IIUC this patch sets unused lanes in idle mode? If yes, then can't we model
> each lane as a separate phy, so that we can power-on/power-off each lane
> independently.

I suggested the same to Shawn previously. I'm interested in seeing his response.

But personally I'm still not sure if that's the most accurate way to
describe this PHY, except for the fact that inevitably, most device
tree bindings get molded to match the related kernel APIs, rather than
the other way around. What if instead, we added an enum mode entry
that represents "finished link training", at which point the PHY would
then know it can power down the unused lanes (that's assuming the PHY
can figure that part out)?

Or if we did re-model this PHY, how are we supposed to handle backward
compatibility? Can the same PHY driver support 2 different of_xlate
methods? I guess we'd have to provide an implementation that sets the
driver up to behave completely differently based on the number of
#phy-cells?

Brian
Shawn Lin July 13, 2017, 2:27 a.m. UTC | #5
Hi Kishon,

On 2017/7/11 12:45, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 16 June 2017 01:47 PM, Shawn Lin wrote:
>> phy_mode was added for switching USB mode purposely as
>> well as phy_set_mode API. However other types of PHY could
>> also have some miscellaneous setting/modes need to be
>> handled. This patch is gonna support this callback for
>> phy-rockchip-pcie and do some power-saving work there.
>> Note that we just stuff in some other values other that the
>> existing phy_mode and convert it in the coressponding driver
>> instead, otherwise we should extend the phy_mode again which
>> it doesn't make sense to add in new driver's specificed value.
>> Overall it looks fine to me as the controller's driver and the
>> phy's driver are paired so that the caller and the consumer should
>> be able to keep the value(mode) in consistent.
> 
> I really don't prefer using an API other that what it is intended for. We have
> to come up with a better way for handling this.

okay.

> 
> IIUC this patch sets unused lanes in idle mode? If yes, then can't we model
> each lane as a separate phy, so that we can power-on/power-off each lane
> independently.

I will have a try and see how far I will go.

Thanks.

> 
> Thanks
> Kishon
>>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>> ---
>>
>>   drivers/phy/rockchip/phy-rockchip-pcie.c | 22 ++++++++++++++++++++++
>>   1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-pcie.c b/drivers/phy/rockchip/phy-rockchip-pcie.c
>> index 6904633..9ffad15 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-pcie.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-pcie.c
>> @@ -255,11 +255,33 @@ static int rockchip_pcie_phy_exit(struct phy *phy)
>>   	return 0;
>>   }
>>   
>> +static int rockchip_pcie_phy_set_mode(struct phy *phy, enum phy_mode mode)
>> +{
>> +	struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
>> +	u8 map = (u8)mode;
>> +	int i;
>> +
>> +	for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
>> +		if (map & BIT(i))
>> +			continue;
>> +
>> +		dev_dbg(&phy->dev, "idling lane %d\n", i);
>> +		regmap_write(rk_phy->reg_base,
>> +			     rk_phy->phy_data->pcie_laneoff,
>> +			     HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
>> +			     PHY_LANE_IDLE_MASK,
>> +			     PHY_LANE_IDLE_A_SHIFT + i));
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   static const struct phy_ops ops = {
>>   	.init		= rockchip_pcie_phy_init,
>>   	.exit		= rockchip_pcie_phy_exit,
>>   	.power_on	= rockchip_pcie_phy_power_on,
>>   	.power_off	= rockchip_pcie_phy_power_off,
>> +	.set_mode	= rockchip_pcie_phy_set_mode,
>>   	.owner		= THIS_MODULE,
>>   };
>>   
>>
> 
> 
>
Brian Norris July 17, 2017, 9:03 p.m. UTC | #6
On Mon, Jul 10, 2017 at 10:20:32PM -0700, Brian Norris wrote:
> Hi Kishon,

Hi again Kishon,

I didn't get a response from you, but Shawn is continuing to send
several versions of a patchset implementing one of these suggestions.
I'd like to ping back here, in the hopes of getting an answer.

> On Mon, Jul 10, 2017 at 9:45 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> > On Friday 16 June 2017 01:47 PM, Shawn Lin wrote:
> > > phy_mode was added for switching USB mode purposely as
> > > well as phy_set_mode API. However other types of PHY could
> > > also have some miscellaneous setting/modes need to be
> > > handled. This patch is gonna support this callback for
> > > phy-rockchip-pcie and do some power-saving work there.
> > > Note that we just stuff in some other values other that the
> > > existing phy_mode and convert it in the coressponding driver
> > > instead, otherwise we should extend the phy_mode again which
> > > it doesn't make sense to add in new driver's specificed value.
> > > Overall it looks fine to me as the controller's driver and the
> > > phy's driver are paired so that the caller and the consumer should
> > > be able to keep the value(mode) in consistent.
> >
> > I really don't prefer using an API other that what it is intended for. We have
> > to come up with a better way for handling this.
> >
> > IIUC this patch sets unused lanes in idle mode? If yes, then can't we model
> > each lane as a separate phy, so that we can power-on/power-off each lane
> > independently.
> 
> I suggested the same to Shawn previously. I'm interested in seeing his response.

Judging by Shawn's subsequent patches, I guess he saw no problem with
this. I'm still not so sure.

> But personally I'm still not sure if that's the most accurate way to
> describe this PHY, except for the fact that inevitably, most device
> tree bindings get molded to match the related kernel APIs, rather than
> the other way around. What if instead, we added an enum mode entry
> that represents "finished link training", at which point the PHY would
> then know it can power down the unused lanes (that's assuming the PHY
> can figure that part out)?

Can I get an answer here? Is it possible that we extend the PHY API with
either a new 'phy_mode', or with some other PCIe-specific extension? As
I said above, it doesn't actually seem like a natural description of the
hardware to say that there are 4 PHYs here, instead of just 1. And then
it puts more burden on the provider/consumer drivers to do a lot of
weird accounting, just so that this single piece of hardware can fit the
current limited set of APIs.

This is not the first time that some concept isn't so easy to fit into
the existing framework. I think it would be prudent to consider ways to
better extend the API to support modes specific to device classes.
You've already done that for some USB pieces, and I think it would make
sense to extend this to PCIe. For instance, we could have the PHY export
things like "number of PCIe lanes", and support callbacks for "disable
unused lanes".

> Or if we did re-model this PHY, how are we supposed to handle backward
> compatibility? Can the same PHY driver support 2 different of_xlate
> methods? I guess we'd have to provide an implementation that sets the
> driver up to behave completely differently based on the number of
> #phy-cells?

I guess Shawn was able to work out some of this. But all the extra
state-tracking and reference counting appears to be hard to get right...

Brian
diff mbox

Patch

diff --git a/drivers/phy/rockchip/phy-rockchip-pcie.c b/drivers/phy/rockchip/phy-rockchip-pcie.c
index 6904633..9ffad15 100644
--- a/drivers/phy/rockchip/phy-rockchip-pcie.c
+++ b/drivers/phy/rockchip/phy-rockchip-pcie.c
@@ -255,11 +255,33 @@  static int rockchip_pcie_phy_exit(struct phy *phy)
 	return 0;
 }
 
+static int rockchip_pcie_phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+	struct rockchip_pcie_phy *rk_phy = phy_get_drvdata(phy);
+	u8 map = (u8)mode;
+	int i;
+
+	for (i = 0; i < PHY_MAX_LANE_NUM; i++) {
+		if (map & BIT(i))
+			continue;
+
+		dev_dbg(&phy->dev, "idling lane %d\n", i);
+		regmap_write(rk_phy->reg_base,
+			     rk_phy->phy_data->pcie_laneoff,
+			     HIWORD_UPDATE(PHY_LANE_IDLE_OFF,
+			     PHY_LANE_IDLE_MASK,
+			     PHY_LANE_IDLE_A_SHIFT + i));
+	}
+
+	return 0;
+}
+
 static const struct phy_ops ops = {
 	.init		= rockchip_pcie_phy_init,
 	.exit		= rockchip_pcie_phy_exit,
 	.power_on	= rockchip_pcie_phy_power_on,
 	.power_off	= rockchip_pcie_phy_power_off,
+	.set_mode	= rockchip_pcie_phy_set_mode,
 	.owner		= THIS_MODULE,
 };