Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Kishon Vijay Abraham I]

On Friday 16 February 2018 06:35 PM, Heiko Stübner wrote:
> Hi Kishon,
> 
> Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I:
>> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
>>> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
>>> only one PHY can connect to DP controller at one time, the other should
>>> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
>>> set this bit means enable PHY 1, clear this bit means enable PHY 0.
>>>
>>> If the board has 2 Type-C ports, the DP driver get the phy id from
>>> devm_of_phy_get_by_index, and then control this switch according to
>>> this id. But some others board only has one Type-C port, it may be PHY 0
>>> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
>>> this switch to PHY driver, the PHY driver can distinguish between PHY 0
>>> and PHY 1, and then write the correct register bit.
>>
>> Changed subject of "Documentation: bindings: add uphy-dp-sel for Rockchip
>> USB Type-C PHY" as suggested by Rob, rebased "phy: rockchip-typec: support
>> DP phy switch" to the latest kernel and merged.
> 
> I'm not sure how far along you are with your merging, but you might want to 
> revert this one.
> 
> In your inbox you should find more recent threads about the type-c phy
> where Rob strongly suggested moving the whole grf registers out of the
> dt and into the driver.
> 
> Enric Balletbo did just that and posted a series (including the dp-move)
> yesterday (refined in a v2 from today).
> 
> Alternatively Enric could rebase his series on top of that recent change.

I can drop this series and take Enric's series. All of them are still in my
local system.

Thanks
Kishon

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Kishon Vijay Abraham I]

On Friday 16 February 2018 06:35 PM, Heiko Stübner wrote:
> Hi Kishon,
> 
> Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I:
>> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
>>> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
>>> only one PHY can connect to DP controller at one time, the other should
>>> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
>>> set this bit means enable PHY 1, clear this bit means enable PHY 0.
>>>
>>> If the board has 2 Type-C ports, the DP driver get the phy id from
>>> devm_of_phy_get_by_index, and then control this switch according to
>>> this id. But some others board only has one Type-C port, it may be PHY 0
>>> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
>>> this switch to PHY driver, the PHY driver can distinguish between PHY 0
>>> and PHY 1, and then write the correct register bit.
>>
>> Changed subject of "Documentation: bindings: add uphy-dp-sel for Rockchip
>> USB Type-C PHY" as suggested by Rob, rebased "phy: rockchip-typec: support
>> DP phy switch" to the latest kernel and merged.
> 
> I'm not sure how far along you are with your merging, but you might want to 
> revert this one.
> 
> In your inbox you should find more recent threads about the type-c phy
> where Rob strongly suggested moving the whole grf registers out of the
> dt and into the driver.
> 
> Enric Balletbo did just that and posted a series (including the dp-move)
> yesterday (refined in a v2 from today).
> 
> Alternatively Enric could rebase his series on top of that recent change.

I can drop this series and take Enric's series. All of them are still in my
local system.

Thanks
Kishon

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi Kishon,

Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I:
> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
> > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> > only one PHY can connect to DP controller at one time, the other should
> > be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> > set this bit means enable PHY 1, clear this bit means enable PHY 0.
> > 
> > If the board has 2 Type-C ports, the DP driver get the phy id from
> > devm_of_phy_get_by_index, and then control this switch according to
> > this id. But some others board only has one Type-C port, it may be PHY 0
> > or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> > this switch to PHY driver, the PHY driver can distinguish between PHY 0
> > and PHY 1, and then write the correct register bit.
> 
> Changed subject of "Documentation: bindings: add uphy-dp-sel for Rockchip
> USB Type-C PHY" as suggested by Rob, rebased "phy: rockchip-typec: support
> DP phy switch" to the latest kernel and merged.

I'm not sure how far along you are with your merging, but you might want to 
revert this one.

In your inbox you should find more recent threads about the type-c phy
where Rob strongly suggested moving the whole grf registers out of the
dt and into the driver.

Enric Balletbo did just that and posted a series (including the dp-move)
yesterday (refined in a v2 from today).

Alternatively Enric could rebase his series on top of that recent change.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi Kishon,

Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I:
> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
> > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> > only one PHY can connect to DP controller at one time, the other should
> > be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> > set this bit means enable PHY 1, clear this bit means enable PHY 0.
> > 
> > If the board has 2 Type-C ports, the DP driver get the phy id from
> > devm_of_phy_get_by_index, and then control this switch according to
> > this id. But some others board only has one Type-C port, it may be PHY 0
> > or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> > this switch to PHY driver, the PHY driver can distinguish between PHY 0
> > and PHY 1, and then write the correct register bit.
> 
> Changed subject of "Documentation: bindings: add uphy-dp-sel for Rockchip
> USB Type-C PHY" as suggested by Rob, rebased "phy: rockchip-typec: support
> DP phy switch" to the latest kernel and merged.

I'm not sure how far along you are with your merging, but you might want to 
revert this one.

In your inbox you should find more recent threads about the type-c phy
where Rob strongly suggested moving the whole grf registers out of the
dt and into the driver.

Enric Balletbo did just that and posted a series (including the dp-move)
yesterday (refined in a v2 from today).

Alternatively Enric could rebase his series on top of that recent change.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Kishon Vijay Abraham I]

Hi,

On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
> 
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit means enable PHY 1, clear this bit means enable PHY 0.
> 
> If the board has 2 Type-C ports, the DP driver get the phy id from
> devm_of_phy_get_by_index, and then control this switch according to
> this id. But some others board only has one Type-C port, it may be PHY 0
> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> this switch to PHY driver, the PHY driver can distinguish between PHY 0
> and PHY 1, and then write the correct register bit.
> 
> 

Changed subject of "Documentation: bindings: add uphy-dp-sel for Rockchip USB
Type-C PHY" as suggested by Rob, rebased "phy: rockchip-typec: support DP phy
switch" to the latest kernel and merged.

Thanks
Kishon

> 
> Chris Zhong (4):
>   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
>   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
>   phy: rockchip-typec: support DP phy switch
>   drm/rockchip: cdn-dp: remove the DP phy switch
> 
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
>  drivers/phy/phy-rockchip-typec.c | 9 +
>  4 files changed, 16 insertions(+), 7 deletions(-)
> 

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Kishon Vijay Abraham I]

Hi,

On Friday 10 February 2017 01:14 PM, Chris Zhong wrote:
> 
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit means enable PHY 1, clear this bit means enable PHY 0.
> 
> If the board has 2 Type-C ports, the DP driver get the phy id from
> devm_of_phy_get_by_index, and then control this switch according to
> this id. But some others board only has one Type-C port, it may be PHY 0
> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> this switch to PHY driver, the PHY driver can distinguish between PHY 0
> and PHY 1, and then write the correct register bit.
> 
> 

Changed subject of "Documentation: bindings: add uphy-dp-sel for Rockchip USB
Type-C PHY" as suggested by Rob, rebased "phy: rockchip-typec: support DP phy
switch" to the latest kernel and merged.

Thanks
Kishon

> 
> Chris Zhong (4):
>   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
>   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
>   phy: rockchip-typec: support DP phy switch
>   drm/rockchip: cdn-dp: remove the DP phy switch
> 
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
>  drivers/phy/phy-rockchip-typec.c | 9 +
>  4 files changed, 16 insertions(+), 7 deletions(-)
> 

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi,

Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson:
> On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner  wrote:
> > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> >> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  
wrote:
> >> >>> Thank you for mentioning this patch.
> >> >>> 
> >> >>> I think the focus of the discussion is: can we put the grf control
> >> >>> bit
> >> >>> to
> >> >>> dts.
> >> >>> 
> >> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >> >>> "uphy_dp_sel"
> >> >>> 
> >> >>> can help to switch these 2 phy. So I think this bit can be considered
> >> >>> as
> >> >>> a
> >> >>> part of
> >> >>> 
> >> >>> Type-C phy, these 2 phy have different bits, just similar to other
> >> >>> bits
> >> >>> (such as "pipe-status").
> >> >>> 
> >> >>> Put them to DTS file might be a accepted practice.
> >> >> 
> >> >> I guess the first step would be finding the person to make a decision.
> >> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> >> options:
> >> >> 
> >> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> >> the other ones next to it.  If anyone happens to try to use an old
> >> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> >> given that the whole type C PHY is not really fully functional
> >> >> upstream, but technically this is a no-no from a device tree
> >> >> perspective.
> >> >> 
> >> >> 2. Change the series to make this property optional.  If it's not
> >> >> there then the code behaves like it always did.  This would address
> >> >> the "compatibility" problem but likely wouldn't actually help any real
> >> >> people, and it would be extra work.
> >> >> 
> >> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> >> put the table in the driver, keyed off the compatible string and base
> >> >> address if the IO memory.
> >> >> 
> >> >> 
> >> >> I can't make this decision.  It's up to those folks who would be
> >> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> >> happy with, however, is the indecision preventing forward progress.
> >> >> We should pick one of the above things and land it.  My own personal
> >> >> bias is #1: just land the series.  No real people will be hurt and
> >> >> it's just adding another property that matches the ones next to it.
> >> > 
> >> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> >> > the past (some for the never used dp output), so personally I don't
> >> > have
> >> > issues with going that route.
> >> > 
> >> >>  From a long term perspective (AKA how I'd write the next driver like
> >> >> 
> >> >> this) I personally lean towards to "tables in the driver, not in the
> >> >> device tree" but quite honestly I'm happy to take whatever direction
> >> >> the maintainers give.
> >> > 
> >> > It looks like we're in agreement here :-) . GRF stuff should not leak
> >> > into
> >> > the devicetree, as it causes endless headaches later. But I guess we'll
> >> > need to live with the ones that happened so far.
> >> 
> >> So, the first step is: move all the private property of tcphy to
> >> drivers/phy/rockchip/phy-rockchip-typec.c.
> >> Second step: new a member: uphy-dp-sel.
> >> In my mind, we should have discussed these properties before, and then I
> >> moved them all into DTS.
> > 
> > Actually, I was agreeing with Doug, that we probably don't need to rework
> > the type-c phy driver. As most properties for it are in the devicetree
> > right now we'll need to support them for backwards-compatiblity anyway.
> > 
> > And yes, there probably was discussion over dts vs. driver-table when the
> > type-c driver was introduced, but I either missed it or wasn't firm enough
> > back then ;-) .
> > 
> > Hence the "we'll need to live with it" for the type-c phy, but should not
> > do similar things in future drivers.
> 
> So I guess now we're just waiting for some agreement from Kishon that
> he's willing to land the PHY change?  Heiko: presumably you could
> apply the DP change to drm-misc?  ...or is there some other process
> needed there?

I was lagging behind a bit with the drm-misc account request but have
done so now. So once I got the hang of how drm-misc works and Kishon
has picked the phy-part I can most likely push the drm part (or Sandy,
depending on who is faster).

As for process, I don't think there is special care necessary. When
you get the intermediate case of phy-change but no drm-change
everything will just revert to how it works now anyway.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi,

Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson:
> On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner  wrote:
> > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> >> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  
wrote:
> >> >>> Thank you for mentioning this patch.
> >> >>> 
> >> >>> I think the focus of the discussion is: can we put the grf control
> >> >>> bit
> >> >>> to
> >> >>> dts.
> >> >>> 
> >> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >> >>> "uphy_dp_sel"
> >> >>> 
> >> >>> can help to switch these 2 phy. So I think this bit can be considered
> >> >>> as
> >> >>> a
> >> >>> part of
> >> >>> 
> >> >>> Type-C phy, these 2 phy have different bits, just similar to other
> >> >>> bits
> >> >>> (such as "pipe-status").
> >> >>> 
> >> >>> Put them to DTS file might be a accepted practice.
> >> >> 
> >> >> I guess the first step would be finding the person to make a decision.
> >> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> >> options:
> >> >> 
> >> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> >> the other ones next to it.  If anyone happens to try to use an old
> >> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> >> given that the whole type C PHY is not really fully functional
> >> >> upstream, but technically this is a no-no from a device tree
> >> >> perspective.
> >> >> 
> >> >> 2. Change the series to make this property optional.  If it's not
> >> >> there then the code behaves like it always did.  This would address
> >> >> the "compatibility" problem but likely wouldn't actually help any real
> >> >> people, and it would be extra work.
> >> >> 
> >> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> >> put the table in the driver, keyed off the compatible string and base
> >> >> address if the IO memory.
> >> >> 
> >> >> 
> >> >> I can't make this decision.  It's up to those folks who would be
> >> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> >> happy with, however, is the indecision preventing forward progress.
> >> >> We should pick one of the above things and land it.  My own personal
> >> >> bias is #1: just land the series.  No real people will be hurt and
> >> >> it's just adding another property that matches the ones next to it.
> >> > 
> >> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> >> > the past (some for the never used dp output), so personally I don't
> >> > have
> >> > issues with going that route.
> >> > 
> >> >>  From a long term perspective (AKA how I'd write the next driver like
> >> >> 
> >> >> this) I personally lean towards to "tables in the driver, not in the
> >> >> device tree" but quite honestly I'm happy to take whatever direction
> >> >> the maintainers give.
> >> > 
> >> > It looks like we're in agreement here :-) . GRF stuff should not leak
> >> > into
> >> > the devicetree, as it causes endless headaches later. But I guess we'll
> >> > need to live with the ones that happened so far.
> >> 
> >> So, the first step is: move all the private property of tcphy to
> >> drivers/phy/rockchip/phy-rockchip-typec.c.
> >> Second step: new a member: uphy-dp-sel.
> >> In my mind, we should have discussed these properties before, and then I
> >> moved them all into DTS.
> > 
> > Actually, I was agreeing with Doug, that we probably don't need to rework
> > the type-c phy driver. As most properties for it are in the devicetree
> > right now we'll need to support them for backwards-compatiblity anyway.
> > 
> > And yes, there probably was discussion over dts vs. driver-table when the
> > type-c driver was introduced, but I either missed it or wasn't firm enough
> > back then ;-) .
> > 
> > Hence the "we'll need to live with it" for the type-c phy, but should not
> > do similar things in future drivers.
> 
> So I guess now we're just waiting for some agreement from Kishon that
> he's willing to land the PHY change?  Heiko: presumably you could
> apply the DP change to drm-misc?  ...or is there some other process
> needed there?

I was lagging behind a bit with the drm-misc account request but have
done so now. So once I got the hang of how drm-misc works and Kishon
has picked the phy-part I can most likely push the drm part (or Sandy,
depending on who is faster).

As for process, I don't think there is special care necessary. When
you get the intermediate case of phy-change but no drm-change
everything will just revert to how it works now anyway.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner  wrote:
> Hi Chris,
>
> Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
>> On 2017年12月02日 05:58, Heiko Stuebner wrote:
>> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
>> >> Hi,
>> >>
>> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
>> >>> Hi Doug
>> >>>
>> >>> Thank you for mentioning this patch.
>> >>>
>> >>> I think the focus of the discussion is: can we put the grf control bit
>> >>> to
>> >>> dts.
>> >>>
>> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
>> >>> "uphy_dp_sel"
>> >>>
>> >>> can help to switch these 2 phy. So I think this bit can be considered as
>> >>> a
>> >>> part of
>> >>>
>> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
>> >>> (such as "pipe-status").
>> >>>
>> >>> Put them to DTS file might be a accepted practice.
>> >>
>> >> I guess the first step would be finding the person to make a decision.
>> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
>> >> options:
>> >>
>> >> 1. Land this series as-is.  This makes the new bit work just like all
>> >> the other ones next to it.  If anyone happens to try to use an old
>> >> device tree on a new kernel they'll break.  Seems rather unlikely
>> >> given that the whole type C PHY is not really fully functional
>> >> upstream, but technically this is a no-no from a device tree
>> >> perspective.
>> >>
>> >> 2. Change the series to make this property optional.  If it's not
>> >> there then the code behaves like it always did.  This would address
>> >> the "compatibility" problem but likely wouldn't actually help any real
>> >> people, and it would be extra work.
>> >>
>> >> 3. Redo the driver to deprecate all the old offsets / bits and just
>> >> put the table in the driver, keyed off the compatible string and base
>> >> address if the IO memory.
>> >>
>> >>
>> >> I can't make this decision.  It's up to those folks who would be
>> >> landing the patch and I'd be happy with any of them.  What I'm less
>> >> happy with, however, is the indecision preventing forward progress.
>> >> We should pick one of the above things and land it.  My own personal
>> >> bias is #1: just land the series.  No real people will be hurt and
>> >> it's just adding another property that matches the ones next to it.
>> >
>> > I'd second that #1 . That whole type-c phy thingy never fully worked in
>> > the past (some for the never used dp output), so personally I don't have
>> > issues with going that route.
>> >
>> >>  From a long term perspective (AKA how I'd write the next driver like
>> >>
>> >> this) I personally lean towards to "tables in the driver, not in the
>> >> device tree" but quite honestly I'm happy to take whatever direction
>> >> the maintainers give.
>> >
>> > It looks like we're in agreement here :-) . GRF stuff should not leak into
>> > the devicetree, as it causes endless headaches later. But I guess we'll
>> > need to live with the ones that happened so far.
>>
>> So, the first step is: move all the private property of tcphy to
>> drivers/phy/rockchip/phy-rockchip-typec.c.
>> Second step: new a member: uphy-dp-sel.
>> In my mind, we should have discussed these properties before, and then I
>> moved them all into DTS.
>
> Actually, I was agreeing with Doug, that we probably don't need to rework the
> type-c phy driver. As most properties for it are in the devicetree right now
> we'll need to support them for backwards-compatiblity anyway.
>
> And yes, there probably was discussion over dts vs. driver-table when the
> type-c driver was introduced, but I either missed it or wasn't firm enough
> back then ;-) .
>
> Hence the "we'll need to live with it" for the type-c phy, but should not
> do similar things in future drivers.

So I guess now we're just waiting for some agreement from Kishon that
he's willing to land the PHY change?  Heiko: presumably you could
apply the DP change to drm-misc?  ...or is there some other process
needed there?

-Doug

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner  wrote:
> Hi Chris,
>
> Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
>> On 2017年12月02日 05:58, Heiko Stuebner wrote:
>> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
>> >> Hi,
>> >>
>> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
>> >>> Hi Doug
>> >>>
>> >>> Thank you for mentioning this patch.
>> >>>
>> >>> I think the focus of the discussion is: can we put the grf control bit
>> >>> to
>> >>> dts.
>> >>>
>> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
>> >>> "uphy_dp_sel"
>> >>>
>> >>> can help to switch these 2 phy. So I think this bit can be considered as
>> >>> a
>> >>> part of
>> >>>
>> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
>> >>> (such as "pipe-status").
>> >>>
>> >>> Put them to DTS file might be a accepted practice.
>> >>
>> >> I guess the first step would be finding the person to make a decision.
>> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
>> >> options:
>> >>
>> >> 1. Land this series as-is.  This makes the new bit work just like all
>> >> the other ones next to it.  If anyone happens to try to use an old
>> >> device tree on a new kernel they'll break.  Seems rather unlikely
>> >> given that the whole type C PHY is not really fully functional
>> >> upstream, but technically this is a no-no from a device tree
>> >> perspective.
>> >>
>> >> 2. Change the series to make this property optional.  If it's not
>> >> there then the code behaves like it always did.  This would address
>> >> the "compatibility" problem but likely wouldn't actually help any real
>> >> people, and it would be extra work.
>> >>
>> >> 3. Redo the driver to deprecate all the old offsets / bits and just
>> >> put the table in the driver, keyed off the compatible string and base
>> >> address if the IO memory.
>> >>
>> >>
>> >> I can't make this decision.  It's up to those folks who would be
>> >> landing the patch and I'd be happy with any of them.  What I'm less
>> >> happy with, however, is the indecision preventing forward progress.
>> >> We should pick one of the above things and land it.  My own personal
>> >> bias is #1: just land the series.  No real people will be hurt and
>> >> it's just adding another property that matches the ones next to it.
>> >
>> > I'd second that #1 . That whole type-c phy thingy never fully worked in
>> > the past (some for the never used dp output), so personally I don't have
>> > issues with going that route.
>> >
>> >>  From a long term perspective (AKA how I'd write the next driver like
>> >>
>> >> this) I personally lean towards to "tables in the driver, not in the
>> >> device tree" but quite honestly I'm happy to take whatever direction
>> >> the maintainers give.
>> >
>> > It looks like we're in agreement here :-) . GRF stuff should not leak into
>> > the devicetree, as it causes endless headaches later. But I guess we'll
>> > need to live with the ones that happened so far.
>>
>> So, the first step is: move all the private property of tcphy to
>> drivers/phy/rockchip/phy-rockchip-typec.c.
>> Second step: new a member: uphy-dp-sel.
>> In my mind, we should have discussed these properties before, and then I
>> moved them all into DTS.
>
> Actually, I was agreeing with Doug, that we probably don't need to rework the
> type-c phy driver. As most properties for it are in the devicetree right now
> we'll need to support them for backwards-compatiblity anyway.
>
> And yes, there probably was discussion over dts vs. driver-table when the
> type-c driver was introduced, but I either missed it or wasn't firm enough
> back then ;-) .
>
> Hence the "we'll need to live with it" for the type-c phy, but should not
> do similar things in future drivers.

So I guess now we're just waiting for some agreement from Kishon that
he's willing to land the PHY change?  Heiko: presumably you could
apply the DP change to drm-misc?  ...or is there some other process
needed there?

-Doug

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi Chris,

Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> Hi,
> >> 
> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> >>> Hi Doug
> >>> 
> >>> Thank you for mentioning this patch.
> >>> 
> >>> I think the focus of the discussion is: can we put the grf control bit
> >>> to
> >>> dts.
> >>> 
> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >>> "uphy_dp_sel"
> >>> 
> >>> can help to switch these 2 phy. So I think this bit can be considered as
> >>> a
> >>> part of
> >>> 
> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
> >>> (such as "pipe-status").
> >>> 
> >>> Put them to DTS file might be a accepted practice.
> >> 
> >> I guess the first step would be finding the person to make a decision.
> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> options:
> >> 
> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> the other ones next to it.  If anyone happens to try to use an old
> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> given that the whole type C PHY is not really fully functional
> >> upstream, but technically this is a no-no from a device tree
> >> perspective.
> >> 
> >> 2. Change the series to make this property optional.  If it's not
> >> there then the code behaves like it always did.  This would address
> >> the "compatibility" problem but likely wouldn't actually help any real
> >> people, and it would be extra work.
> >> 
> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> put the table in the driver, keyed off the compatible string and base
> >> address if the IO memory.
> >> 
> >> 
> >> I can't make this decision.  It's up to those folks who would be
> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> happy with, however, is the indecision preventing forward progress.
> >> We should pick one of the above things and land it.  My own personal
> >> bias is #1: just land the series.  No real people will be hurt and
> >> it's just adding another property that matches the ones next to it.
> > 
> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> > the past (some for the never used dp output), so personally I don't have
> > issues with going that route.
> > 
> >>  From a long term perspective (AKA how I'd write the next driver like
> >> 
> >> this) I personally lean towards to "tables in the driver, not in the
> >> device tree" but quite honestly I'm happy to take whatever direction
> >> the maintainers give.
> > 
> > It looks like we're in agreement here :-) . GRF stuff should not leak into
> > the devicetree, as it causes endless headaches later. But I guess we'll
> > need to live with the ones that happened so far.
> 
> So, the first step is: move all the private property of tcphy to
> drivers/phy/rockchip/phy-rockchip-typec.c.
> Second step: new a member: uphy-dp-sel.
> In my mind, we should have discussed these properties before, and then I
> moved them all into DTS.

Actually, I was agreeing with Doug, that we probably don't need to rework the 
type-c phy driver. As most properties for it are in the devicetree right now
we'll need to support them for backwards-compatiblity anyway.

And yes, there probably was discussion over dts vs. driver-table when the
type-c driver was introduced, but I either missed it or wasn't firm enough
back then ;-) .

Hence the "we'll need to live with it" for the type-c phy, but should not
do similar things in future drivers.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi Chris,

Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> Hi,
> >> 
> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> >>> Hi Doug
> >>> 
> >>> Thank you for mentioning this patch.
> >>> 
> >>> I think the focus of the discussion is: can we put the grf control bit
> >>> to
> >>> dts.
> >>> 
> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >>> "uphy_dp_sel"
> >>> 
> >>> can help to switch these 2 phy. So I think this bit can be considered as
> >>> a
> >>> part of
> >>> 
> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
> >>> (such as "pipe-status").
> >>> 
> >>> Put them to DTS file might be a accepted practice.
> >> 
> >> I guess the first step would be finding the person to make a decision.
> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> options:
> >> 
> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> the other ones next to it.  If anyone happens to try to use an old
> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> given that the whole type C PHY is not really fully functional
> >> upstream, but technically this is a no-no from a device tree
> >> perspective.
> >> 
> >> 2. Change the series to make this property optional.  If it's not
> >> there then the code behaves like it always did.  This would address
> >> the "compatibility" problem but likely wouldn't actually help any real
> >> people, and it would be extra work.
> >> 
> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> put the table in the driver, keyed off the compatible string and base
> >> address if the IO memory.
> >> 
> >> 
> >> I can't make this decision.  It's up to those folks who would be
> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> happy with, however, is the indecision preventing forward progress.
> >> We should pick one of the above things and land it.  My own personal
> >> bias is #1: just land the series.  No real people will be hurt and
> >> it's just adding another property that matches the ones next to it.
> > 
> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> > the past (some for the never used dp output), so personally I don't have
> > issues with going that route.
> > 
> >>  From a long term perspective (AKA how I'd write the next driver like
> >> 
> >> this) I personally lean towards to "tables in the driver, not in the
> >> device tree" but quite honestly I'm happy to take whatever direction
> >> the maintainers give.
> > 
> > It looks like we're in agreement here :-) . GRF stuff should not leak into
> > the devicetree, as it causes endless headaches later. But I guess we'll
> > need to live with the ones that happened so far.
> 
> So, the first step is: move all the private property of tcphy to
> drivers/phy/rockchip/phy-rockchip-typec.c.
> Second step: new a member: uphy-dp-sel.
> In my mind, we should have discussed these properties before, and then I
> moved them all into DTS.

Actually, I was agreeing with Doug, that we probably don't need to rework the 
type-c phy driver. As most properties for it are in the devicetree right now
we'll need to support them for backwards-compatiblity anyway.

And yes, there probably was discussion over dts vs. driver-table when the
type-c driver was introduced, but I either missed it or wasn't firm enough
back then ;-) .

Hence the "we'll need to live with it" for the type-c phy, but should not
do similar things in future drivers.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

Hi Heiko


On 2017??12??02?? 05:58, Heiko Stuebner wrote:

Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:

Hi,

On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:

Hi Doug

Thank you for mentioning this patch.

I think the focus of the discussion is: can we put the grf control bit to
dts.

The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"

can help to switch these 2 phy. So I think this bit can be considered as a
part of

Type-C phy, these 2 phy have different bits, just similar to other bits
(such as "pipe-status").

Put them to DTS file might be a accepted practice.

I guess the first step would be finding the person to make a decision.
Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
options:

1. Land this series as-is.  This makes the new bit work just like all
the other ones next to it.  If anyone happens to try to use an old
device tree on a new kernel they'll break.  Seems rather unlikely
given that the whole type C PHY is not really fully functional
upstream, but technically this is a no-no from a device tree
perspective.

2. Change the series to make this property optional.  If it's not
there then the code behaves like it always did.  This would address
the "compatibility" problem but likely wouldn't actually help any real
people, and it would be extra work.

3. Redo the driver to deprecate all the old offsets / bits and just
put the table in the driver, keyed off the compatible string and base
address if the IO memory.


I can't make this decision.  It's up to those folks who would be
landing the patch and I'd be happy with any of them.  What I'm less
happy with, however, is the indecision preventing forward progress.
We should pick one of the above things and land it.  My own personal
bias is #1: just land the series.  No real people will be hurt and
it's just adding another property that matches the ones next to it.

I'd second that #1 . That whole type-c phy thingy never fully worked in
the past (some for the never used dp output), so personally I don't have
issues with going that route.



 From a long term perspective (AKA how I'd write the next driver like
this) I personally lean towards to "tables in the driver, not in the
device tree" but quite honestly I'm happy to take whatever direction
the maintainers give.

It looks like we're in agreement here :-) . GRF stuff should not leak into
the devicetree, as it causes endless headaches later. But I guess we'll
need to live with the ones that happened so far.

So, the first step is: move all the private property of tcphy to 
drivers/phy/rockchip/phy-rockchip-typec.c.

Second step: new a member: uphy-dp-sel.
In my mind, we should have discussed these properties before, and then I 
moved them all into DTS.










--
Chris Zhong

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

Hi Heiko


On 2017??12??02?? 05:58, Heiko Stuebner wrote:

Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:

Hi,

On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:

Hi Doug

Thank you for mentioning this patch.

I think the focus of the discussion is: can we put the grf control bit to
dts.

The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"

can help to switch these 2 phy. So I think this bit can be considered as a
part of

Type-C phy, these 2 phy have different bits, just similar to other bits
(such as "pipe-status").

Put them to DTS file might be a accepted practice.

I guess the first step would be finding the person to make a decision.
Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
options:

1. Land this series as-is.  This makes the new bit work just like all
the other ones next to it.  If anyone happens to try to use an old
device tree on a new kernel they'll break.  Seems rather unlikely
given that the whole type C PHY is not really fully functional
upstream, but technically this is a no-no from a device tree
perspective.

2. Change the series to make this property optional.  If it's not
there then the code behaves like it always did.  This would address
the "compatibility" problem but likely wouldn't actually help any real
people, and it would be extra work.

3. Redo the driver to deprecate all the old offsets / bits and just
put the table in the driver, keyed off the compatible string and base
address if the IO memory.


I can't make this decision.  It's up to those folks who would be
landing the patch and I'd be happy with any of them.  What I'm less
happy with, however, is the indecision preventing forward progress.
We should pick one of the above things and land it.  My own personal
bias is #1: just land the series.  No real people will be hurt and
it's just adding another property that matches the ones next to it.

I'd second that #1 . That whole type-c phy thingy never fully worked in
the past (some for the never used dp output), so personally I don't have
issues with going that route.



 From a long term perspective (AKA how I'd write the next driver like
this) I personally lean towards to "tables in the driver, not in the
device tree" but quite honestly I'm happy to take whatever direction
the maintainers give.

It looks like we're in agreement here :-) . GRF stuff should not leak into
the devicetree, as it causes endless headaches later. But I guess we'll
need to live with the ones that happened so far.

So, the first step is: move all the private property of tcphy to 
drivers/phy/rockchip/phy-rockchip-typec.c.

Second step: new a member: uphy-dp-sel.
In my mind, we should have discussed these properties before, and then I 
moved them all into DTS.










--
Chris Zhong

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stuebner]

Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> Hi,
> 
> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> > Hi Doug
> >
> > Thank you for mentioning this patch.
> >
> > I think the focus of the discussion is: can we put the grf control bit to
> > dts.
> >
> > The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"
> >
> > can help to switch these 2 phy. So I think this bit can be considered as a
> > part of
> >
> > Type-C phy, these 2 phy have different bits, just similar to other bits
> > (such as "pipe-status").
> >
> > Put them to DTS file might be a accepted practice.
> 
> I guess the first step would be finding the person to make a decision.
> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> options:
> 
> 1. Land this series as-is.  This makes the new bit work just like all
> the other ones next to it.  If anyone happens to try to use an old
> device tree on a new kernel they'll break.  Seems rather unlikely
> given that the whole type C PHY is not really fully functional
> upstream, but technically this is a no-no from a device tree
> perspective.
> 
> 2. Change the series to make this property optional.  If it's not
> there then the code behaves like it always did.  This would address
> the "compatibility" problem but likely wouldn't actually help any real
> people, and it would be extra work.
> 
> 3. Redo the driver to deprecate all the old offsets / bits and just
> put the table in the driver, keyed off the compatible string and base
> address if the IO memory.
> 
> 
> I can't make this decision.  It's up to those folks who would be
> landing the patch and I'd be happy with any of them.  What I'm less
> happy with, however, is the indecision preventing forward progress.
> We should pick one of the above things and land it.  My own personal
> bias is #1: just land the series.  No real people will be hurt and
> it's just adding another property that matches the ones next to it.

I'd second that #1 . That whole type-c phy thingy never fully worked in
the past (some for the never used dp output), so personally I don't have
issues with going that route.


> From a long term perspective (AKA how I'd write the next driver like
> this) I personally lean towards to "tables in the driver, not in the
> device tree" but quite honestly I'm happy to take whatever direction
> the maintainers give.

It looks like we're in agreement here :-) . GRF stuff should not leak into
the devicetree, as it causes endless headaches later. But I guess we'll
need to live with the ones that happened so far.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stuebner]

Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> Hi,
> 
> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> > Hi Doug
> >
> > Thank you for mentioning this patch.
> >
> > I think the focus of the discussion is: can we put the grf control bit to
> > dts.
> >
> > The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"
> >
> > can help to switch these 2 phy. So I think this bit can be considered as a
> > part of
> >
> > Type-C phy, these 2 phy have different bits, just similar to other bits
> > (such as "pipe-status").
> >
> > Put them to DTS file might be a accepted practice.
> 
> I guess the first step would be finding the person to make a decision.
> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> options:
> 
> 1. Land this series as-is.  This makes the new bit work just like all
> the other ones next to it.  If anyone happens to try to use an old
> device tree on a new kernel they'll break.  Seems rather unlikely
> given that the whole type C PHY is not really fully functional
> upstream, but technically this is a no-no from a device tree
> perspective.
> 
> 2. Change the series to make this property optional.  If it's not
> there then the code behaves like it always did.  This would address
> the "compatibility" problem but likely wouldn't actually help any real
> people, and it would be extra work.
> 
> 3. Redo the driver to deprecate all the old offsets / bits and just
> put the table in the driver, keyed off the compatible string and base
> address if the IO memory.
> 
> 
> I can't make this decision.  It's up to those folks who would be
> landing the patch and I'd be happy with any of them.  What I'm less
> happy with, however, is the indecision preventing forward progress.
> We should pick one of the above things and land it.  My own personal
> bias is #1: just land the series.  No real people will be hurt and
> it's just adding another property that matches the ones next to it.

I'd second that #1 . That whole type-c phy thingy never fully worked in
the past (some for the never used dp output), so personally I don't have
issues with going that route.


> From a long term perspective (AKA how I'd write the next driver like
> this) I personally lean towards to "tables in the driver, not in the
> device tree" but quite honestly I'm happy to take whatever direction
> the maintainers give.

It looks like we're in agreement here :-) . GRF stuff should not leak into
the devicetree, as it causes endless headaches later. But I guess we'll
need to live with the ones that happened so far.


Heiko

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> Hi Doug
>
> Thank you for mentioning this patch.
>
> I think the focus of the discussion is: can we put the grf control bit to
> dts.
>
> The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"
>
> can help to switch these 2 phy. So I think this bit can be considered as a
> part of
>
> Type-C phy, these 2 phy have different bits, just similar to other bits
> (such as "pipe-status").
>
> Put them to DTS file might be a accepted practice.

I guess the first step would be finding the person to make a decision.
Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
options:

1. Land this series as-is.  This makes the new bit work just like all
the other ones next to it.  If anyone happens to try to use an old
device tree on a new kernel they'll break.  Seems rather unlikely
given that the whole type C PHY is not really fully functional
upstream, but technically this is a no-no from a device tree
perspective.

2. Change the series to make this property optional.  If it's not
there then the code behaves like it always did.  This would address
the "compatibility" problem but likely wouldn't actually help any real
people, and it would be extra work.

3. Redo the driver to deprecate all the old offsets / bits and just
put the table in the driver, keyed off the compatible string and base
address if the IO memory.


I can't make this decision.  It's up to those folks who would be
landing the patch and I'd be happy with any of them.  What I'm less
happy with, however, is the indecision preventing forward progress.
We should pick one of the above things and land it.  My own personal
bias is #1: just land the series.  No real people will be hurt and
it's just adding another property that matches the ones next to it.

>From a long term perspective (AKA how I'd write the next driver like
this) I personally lean towards to "tables in the driver, not in the
device tree" but quite honestly I'm happy to take whatever direction
the maintainers give.


-Doug

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
> Hi Doug
>
> Thank you for mentioning this patch.
>
> I think the focus of the discussion is: can we put the grf control bit to
> dts.
>
> The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"
>
> can help to switch these 2 phy. So I think this bit can be considered as a
> part of
>
> Type-C phy, these 2 phy have different bits, just similar to other bits
> (such as "pipe-status").
>
> Put them to DTS file might be a accepted practice.

I guess the first step would be finding the person to make a decision.
Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
options:

1. Land this series as-is.  This makes the new bit work just like all
the other ones next to it.  If anyone happens to try to use an old
device tree on a new kernel they'll break.  Seems rather unlikely
given that the whole type C PHY is not really fully functional
upstream, but technically this is a no-no from a device tree
perspective.

2. Change the series to make this property optional.  If it's not
there then the code behaves like it always did.  This would address
the "compatibility" problem but likely wouldn't actually help any real
people, and it would be extra work.

3. Redo the driver to deprecate all the old offsets / bits and just
put the table in the driver, keyed off the compatible string and base
address if the IO memory.


I can't make this decision.  It's up to those folks who would be
landing the patch and I'd be happy with any of them.  What I'm less
happy with, however, is the indecision preventing forward progress.
We should pick one of the above things and land it.  My own personal
bias is #1: just land the series.  No real people will be hurt and
it's just adding another property that matches the ones next to it.

>From a long term perspective (AKA how I'd write the next driver like
this) I personally lean towards to "tables in the driver, not in the
device tree" but quite honestly I'm happy to take whatever direction
the maintainers give.


-Doug

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

Hi Doug

Thank you for mentioning this patch.

I think the focus of the discussion is: can we put the grf control bit 
to dts.


The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"

can help to switch these 2 phy. So I think this bit can be considered as 
a part of


Type-C phy, these 2 phy have different bits, just similar to other bits 
(such as "pipe-status").


Put them to DTS file might be a accepted practice.



On 2017年11月29日 07:32, Doug Anderson wrote:

Hi,

On Thu, Feb 9, 2017 at 11:44 PM, Chris Zhong  wrote:

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

If the board has 2 Type-C ports, the DP driver get the phy id from
devm_of_phy_get_by_index, and then control this switch according to
this id. But some others board only has one Type-C port, it may be PHY 0
or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
this switch to PHY driver, the PHY driver can distinguish between PHY 0
and PHY 1, and then write the correct register bit.



Chris Zhong (4):
   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
   phy: rockchip-typec: support DP phy switch
   drm/rockchip: cdn-dp: remove the DP phy switch

  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
  drivers/phy/phy-rockchip-typec.c | 9 +
  4 files changed, 16 insertions(+), 7 deletions(-)

What ever happened to this series?  It seemed like it just dropped on
the floor...

There was a bit of contention on patch #3
 about the fact that we
were specifying addresses in the device tree vs. hardcoding them in
the driver.  Any way we can just make a decision and go with it?


-Doug





--
Chris Zhong

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

Hi Doug

Thank you for mentioning this patch.

I think the focus of the discussion is: can we put the grf control bit 
to dts.


The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"

can help to switch these 2 phy. So I think this bit can be considered as 
a part of


Type-C phy, these 2 phy have different bits, just similar to other bits 
(such as "pipe-status").


Put them to DTS file might be a accepted practice.



On 2017年11月29日 07:32, Doug Anderson wrote:

Hi,

On Thu, Feb 9, 2017 at 11:44 PM, Chris Zhong  wrote:

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

If the board has 2 Type-C ports, the DP driver get the phy id from
devm_of_phy_get_by_index, and then control this switch according to
this id. But some others board only has one Type-C port, it may be PHY 0
or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
this switch to PHY driver, the PHY driver can distinguish between PHY 0
and PHY 1, and then write the correct register bit.



Chris Zhong (4):
   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
   phy: rockchip-typec: support DP phy switch
   drm/rockchip: cdn-dp: remove the DP phy switch

  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
  drivers/phy/phy-rockchip-typec.c | 9 +
  4 files changed, 16 insertions(+), 7 deletions(-)

What ever happened to this series?  It seemed like it just dropped on
the floor...

There was a bit of contention on patch #3
 about the fact that we
were specifying addresses in the device tree vs. hardcoding them in
the driver.  Any way we can just make a decision and go with it?


-Doug





--
Chris Zhong

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Thu, Feb 9, 2017 at 11:44 PM, Chris Zhong  wrote:
>
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit means enable PHY 1, clear this bit means enable PHY 0.
>
> If the board has 2 Type-C ports, the DP driver get the phy id from
> devm_of_phy_get_by_index, and then control this switch according to
> this id. But some others board only has one Type-C port, it may be PHY 0
> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> this switch to PHY driver, the PHY driver can distinguish between PHY 0
> and PHY 1, and then write the correct register bit.
>
>
>
> Chris Zhong (4):
>   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
>   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
>   phy: rockchip-typec: support DP phy switch
>   drm/rockchip: cdn-dp: remove the DP phy switch
>
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
>  drivers/phy/phy-rockchip-typec.c | 9 +
>  4 files changed, 16 insertions(+), 7 deletions(-)

What ever happened to this series?  It seemed like it just dropped on
the floor...

There was a bit of contention on patch #3
 about the fact that we
were specifying addresses in the device tree vs. hardcoding them in
the driver.  Any way we can just make a decision and go with it?


-Doug

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Thu, Feb 9, 2017 at 11:44 PM, Chris Zhong  wrote:
>
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit means enable PHY 1, clear this bit means enable PHY 0.
>
> If the board has 2 Type-C ports, the DP driver get the phy id from
> devm_of_phy_get_by_index, and then control this switch according to
> this id. But some others board only has one Type-C port, it may be PHY 0
> or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> this switch to PHY driver, the PHY driver can distinguish between PHY 0
> and PHY 1, and then write the correct register bit.
>
>
>
> Chris Zhong (4):
>   Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
>   arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
>   phy: rockchip-typec: support DP phy switch
>   drm/rockchip: cdn-dp: remove the DP phy switch
>
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>  drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
>  drivers/phy/phy-rockchip-typec.c | 9 +
>  4 files changed, 16 insertions(+), 7 deletions(-)

What ever happened to this series?  It seemed like it just dropped on
the floor...

There was a bit of contention on patch #3
 about the fact that we
were specifying addresses in the device tree vs. hardcoding them in
the driver.  Any way we can just make a decision and go with it?


-Doug

[PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

If the board has 2 Type-C ports, the DP driver get the phy id from
devm_of_phy_get_by_index, and then control this switch according to
this id. But some others board only has one Type-C port, it may be PHY 0
or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
this switch to PHY driver, the PHY driver can distinguish between PHY 0
and PHY 1, and then write the correct register bit.



Chris Zhong (4):
  Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
  arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
  phy: rockchip-typec: support DP phy switch
  drm/rockchip: cdn-dp: remove the DP phy switch

 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
 drivers/phy/phy-rockchip-typec.c | 9 +
 4 files changed, 16 insertions(+), 7 deletions(-)

-- 
2.6.3

[PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

If the board has 2 Type-C ports, the DP driver get the phy id from
devm_of_phy_get_by_index, and then control this switch according to
this id. But some others board only has one Type-C port, it may be PHY 0
or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
this switch to PHY driver, the PHY driver can distinguish between PHY 0
and PHY 1, and then write the correct register bit.



Chris Zhong (4):
  Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
  arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
  phy: rockchip-typec: support DP phy switch
  drm/rockchip: cdn-dp: remove the DP phy switch

 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
 drivers/phy/phy-rockchip-typec.c | 9 +
 4 files changed, 16 insertions(+), 7 deletions(-)

-- 
2.6.3