Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1594262 > unrolled thread

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

Started byStephen Boyd <sboyd@codeaurora.org>
First post2017-03-07 15:20 +0100
Last post2017-03-08 08:20 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy Stephen Boyd <sboyd@codeaurora.org> - 2017-03-07 15:20 +0100
    Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy Vivek Gautam <vivek.gautam@codeaurora.org> - 2017-03-08 08:20 +0100

#1594262 — Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

FromStephen Boyd <sboyd@codeaurora.org>
Date2017-03-07 15:20 +0100
SubjectRe: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy
Message-ID<tio81-ag-9@gated-at.bofh.it>
(Not sure I replied so here it is)

On 01/27, Vivek Gautam wrote:
> 
> 
> On 01/27/2017 05:13 AM, Stephen Boyd wrote:
> >On 01/24, Vivek Gautam wrote:
> 
> From "./Documentation/devicetree/bindings/graph.txt" -
> "The device tree graph bindings described herein abstract more complex
> devices that can have multiple specifiable ports, each of which can be
> linked to one or more ports of other devices."
> 
> So, this means we use 'port', 'ports' and 'endpoint' for devices whose one
> or more ports is connected to other device's one or more ports.
> 
> I can use 'lane' for the node name here.

Ok.

> 
> >
> >>                                 reg = <0x035000 0x130>,
> >>                                         <0x035200 0x200>,
> >>                                         <0x035400 0x1dc>;
> >>                                 #phy-cells = <0>;
> >>
> >>                                 clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
> >>                                 clock-names = "pipe0";
> >>                                 resets = <&gcc GCC_PCIE_0_PHY_BCR>;
> >>                                 reset-names = "lane0";
> >>                         };
> >>
> >>                       pciephy_p1: port@1 {
> >>                                 reg = <0x036000 0x130>,
> >>                                         <0x036200 0x200>,
> >>                                         <0x036400 0x1dc>;
> >>                                 #phy-cells = <0>;
> >>
> >>                                 clocks = <&gcc GCC_PCIE_1_PIPE_CLK>;
> >>                                 clock-names = "pipe1";
> >>                                 resets = <&gcc GCC_PCIE_1_PHY_BCR>;
> >>                                 reset-names = "lane1";
> >>                         };
> >>
> >>                         pciephy_p2: port@2 {
> >>                                 reg = <0x037000 0x130>,
> >>                                         <0x037200 0x200>,
> >>                                         <0x037400 0x1dc>;
> >>                                 #phy-cells = <0>;
> >>
> >>                                 clocks = <&gcc GCC_PCIE_2_PIPE_CLK>;
> >>                                 clock-names = "pipe2";
> >>                                 resets = <&gcc GCC_PCIE_2_PHY_BCR>;
> >>                                 reset-names = "lane2";
> >>                         };
> >>                 };
> >>--------------------
> >>
> >>let me know if this looks okay.
> >>
> >>
> >What's the plan for non-pcie qmp phy binding? In that case we
> >don't have ports, so it gets folded into one node?
> >
> The non-pcie qmp phys still have one lane, that provides tx/rx.
> 
> I am of the opinion that we don't have two different ways to create
> phys in the driver, and keep one port/lane for such phys in dt.
> 

Ok so we would still have a subnode in that case. Sounds ok.

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

[toc] | [next] | [standalone]


#1594888

FromVivek Gautam <vivek.gautam@codeaurora.org>
Date2017-03-08 08:20 +0100
Message-ID<tiE37-35s-5@gated-at.bofh.it>
In reply to#1594262

On 03/07/2017 07:30 PM, Stephen Boyd wrote:
> (Not sure I replied so here it is)
>
> On 01/27, Vivek Gautam wrote:
>>
>> On 01/27/2017 05:13 AM, Stephen Boyd wrote:
>>> On 01/24, Vivek Gautam wrote:
>>  From "./Documentation/devicetree/bindings/graph.txt" -
>> "The device tree graph bindings described herein abstract more complex
>> devices that can have multiple specifiable ports, each of which can be
>> linked to one or more ports of other devices."
>>
>> So, this means we use 'port', 'ports' and 'endpoint' for devices whose one
>> or more ports is connected to other device's one or more ports.
>>
>> I can use 'lane' for the node name here.
> Ok.
>
>>>>                                  reg = <0x035000 0x130>,
>>>>                                          <0x035200 0x200>,
>>>>                                          <0x035400 0x1dc>;
>>>>                                  #phy-cells = <0>;
>>>>
>>>>                                  clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
>>>>                                  clock-names = "pipe0";
>>>>                                  resets = <&gcc GCC_PCIE_0_PHY_BCR>;
>>>>                                  reset-names = "lane0";
>>>>                          };
>>>>
>>>>                        pciephy_p1: port@1 {
>>>>                                  reg = <0x036000 0x130>,
>>>>                                          <0x036200 0x200>,
>>>>                                          <0x036400 0x1dc>;
>>>>                                  #phy-cells = <0>;
>>>>
>>>>                                  clocks = <&gcc GCC_PCIE_1_PIPE_CLK>;
>>>>                                  clock-names = "pipe1";
>>>>                                  resets = <&gcc GCC_PCIE_1_PHY_BCR>;
>>>>                                  reset-names = "lane1";
>>>>                          };
>>>>
>>>>                          pciephy_p2: port@2 {
>>>>                                  reg = <0x037000 0x130>,
>>>>                                          <0x037200 0x200>,
>>>>                                          <0x037400 0x1dc>;
>>>>                                  #phy-cells = <0>;
>>>>
>>>>                                  clocks = <&gcc GCC_PCIE_2_PIPE_CLK>;
>>>>                                  clock-names = "pipe2";
>>>>                                  resets = <&gcc GCC_PCIE_2_PHY_BCR>;
>>>>                                  reset-names = "lane2";
>>>>                          };
>>>>                  };
>>>> --------------------
>>>>
>>>> let me know if this looks okay.
>>>>
>>>>
>>> What's the plan for non-pcie qmp phy binding? In that case we
>>> don't have ports, so it gets folded into one node?
>>>
>> The non-pcie qmp phys still have one lane, that provides tx/rx.
>>
>> I am of the opinion that we don't have two different ways to create
>> phys in the driver, and keep one port/lane for such phys in dt.
>>
> Ok so we would still have a subnode in that case. Sounds ok.

Cool.

Thanks
Vivek

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web