linux-kernel - RE: [PATCH 1/2] dt-bindings: power: Add ZynqMP power domain bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <SN1PR02MB37582339D5B3937748F4D9ACB8900@SN1PR02MB3758.namprd02.prod.outlook.com>
Date:   Fri, 18 May 2018 21:18:35 +0000
From:   Jolly Shah <JOLLYS@...inx.com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
CC:     Matthias Brugger <matthias.bgg@...il.com>,
        Andy Gross <andy.gross@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Björn Andersson <bjorn.andersson@...aro.org>,
        "sean.wang@...iatek.com" <sean.wang@...iatek.com>,
        Michal Simek <michal.simek@...inx.com>,
        "Mark Rutland" <mark.rutland@....com>,
        Rajan Vaja <RAJANV@...inx.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Rob Herring <robh@...nel.org>
Subject: RE: [PATCH 1/2] dt-bindings: power: Add ZynqMP power domain bindings

Hi Marek,

> -----Original Message-----
> From: Marek Szyprowski [mailto:m.szyprowski@...sung.com]
> Sent: Thursday, May 17, 2018 11:31 PM
> To: Jolly Shah <JOLLYS@...inx.com>; Geert Uytterhoeven <geert@...ux-
> m68k.org>; Rob Herring <robh@...nel.org>
> Cc: Matthias Brugger <matthias.bgg@...il.com>; Andy Gross
> <andy.gross@...aro.org>; Shawn Guo <shawnguo@...nel.org>; Geert
> Uytterhoeven <geert+renesas@...der.be>; Björn Andersson
> <bjorn.andersson@...aro.org>; sean.wang@...iatek.com; Michal Simek
> <michal.simek@...inx.com>; Mark Rutland <mark.rutland@....com>; Rajan
> Vaja <RAJANV@...inx.com>; open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS <devicetree@...r.kernel.org>; Linux ARM <linux-arm-
> kernel@...ts.infradead.org>; Linux Kernel Mailing List <linux-
> kernel@...r.kernel.org>
> Subject: Re: [PATCH 1/2] dt-bindings: power: Add ZynqMP power domain
> bindings
> 
> Hi Jolly,
> 
> On 2018-05-17 23:10, Jolly Shah wrote:
> 
> >>>>>> +Example:
> >>>>>> +     zynqmp-genpd {
> >>>>>> +             compatible = "xlnx,zynqmp-genpd";
> >>>>> What's the control interface for controlling the domains?
> >>>>>> +
> >>>>>> +             pd_usb0: pd-usb0 {
> >>>>>> +                     pd-id = <22>;
> >>>>>> +                     #power-domain-cells = <0>;
> >>>>> There's no need for all these sub nodes. Make #power-domain-cells
> >>>>> 1 and put the id in the cell value.
> >>>> That was my first reaction, too...
> >>>>>> +             };
> >>>>>> +
> >>>>>> +             pd_sata: pd-sata {
> >>>>>> +                     pd-id = <28>;
> >>>>>> +                     #power-domain-cells = <0>;
> >>>>>> +             };
> >>>>>> +
> >>>>>> +             pd_gpu: pd-gpu {
> >>>>>> +                     pd-id = <58 20 21>;
> >>>> ... until I saw the above.
> >>>> Controlling the GPU power area requires controlling 3 physical areas?
> >>>>
> >>>> However, doing it this way may bite you in the future, if a need
> >>>> arises to control a subset. And what about power up/down order?
> >>> What about defining 3 separate domains and arranging them in
> >>> parent-child relationship? generic power domains already supports
> >>> that and this allows to nicely define the power on/off order.
> >>>
> >>>>>> +                     #power-domain-cells = <0x0>;
> >>>>>> +             };
> >>>>>> +     };
> >> I agree it should be arranged in as parent child order to control
> >> subset or control order. Will incorporate those changes in next version.
> >
> > As suggested, I tried out parent, child approach. However what I found is
> Genpd core takes care of parent child dependencies for power on off routines
> only. In our case, We need them in attach-detach routines too. In that case, we
> need to handle dependencies manually for those routines. Please suggest better
> approach, if any.
> 
> What do you mean to handle attach-detach?
> 
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland

For our power domain driver,  we request usage of these nodes in attach routines and power them on in power on routine. So for below specific case, when attach_dev is called, all 3 nodes need to be requested.

> >>>>>> +             pd_gpu: pd-gpu {
> >>>>>> +                     pd-id = <58 20 21>;

Thanks,
Jolly Shah