Hi Stefano
> -----Original Message-----
> From: linux-remoteproc-owner@xxxxxxxxxxxxxxx <linux-remoteproc-
> owner@xxxxxxxxxxxxxxx> On Behalf Of Ben Levinsky
> Sent: Tuesday, August 18, 2020 7:24 AM
> To: Stefano Stabellini <stefanos@xxxxxxxxxx>
> Cc: Michal Simek <michals@xxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx;
> mathieu.poirier@xxxxxxxxxx; Ed T. Mooring <emooring@xxxxxxxxxx>; linux-
> remoteproc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> robh+dt@xxxxxxxxxx; Jiaying Liang <jliang@xxxxxxxxxx>; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [PATCH v8 2/5] firmware: xilinx: Add shutdown/wakeup APIs
>
>
>
> > -----Original Message-----
> > From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> > Sent: Thursday, August 13, 2020 1:36 PM
> > To: Ben Levinsky <BLEVINSK@xxxxxxxxxx>
> > Cc: Stefano Stabellini <stefanos@xxxxxxxxxx>; Michal Simek
> > <michals@xxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx;
> > mathieu.poirier@xxxxxxxxxx; Ed T. Mooring <emooring@xxxxxxxxxx>; linux-
> > remoteproc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > robh+dt@xxxxxxxxxx; Jiaying Liang <jliang@xxxxxxxxxx>; linux-arm-
> > kernel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v8 2/5] firmware: xilinx: Add shutdown/wakeup APIs
> >
> > On Mon, 10 Aug 2020, Ben Levinsky wrote:
> > > Add shutdown/wakeup a resource eemi operations to shutdown
> > > or bringup a resource.
> > >
> > > Signed-off-by: Ben Levinsky <ben.levinsky@xxxxxxxxxx>
> > > ---
> > > v3:
> > > - add xilinx-related platform mgmt fn's instead of wrapping around
> > > function pointer in xilinx eemi ops struct
> > > - fix formatting
> > > v4:
> > > - add default values for enumv3:
> > > - add xilinx-related platform mgmt fn's instead of wrapping around
> > > function pointer in xilinx eemi ops struct
> > > - fix formatting
> > > v4:
> > > - add default values for enum
> > > ---
> > > drivers/firmware/xilinx/zynqmp.c | 35
> ++++++++++++++++++++++++++++
> > > include/linux/firmware/xlnx-zynqmp.h | 22 +++++++++++++++++
> > > 2 files changed, 57 insertions(+)
> > >
> > > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > b/drivers/firmware/xilinx/zynqmp.c
> > > index 8d1ff2454e2e..f1a0bd35deeb 100644
> > > --- a/drivers/firmware/xilinx/zynqmp.c
> > > +++ b/drivers/firmware/xilinx/zynqmp.c
> > > @@ -846,6 +846,41 @@ int zynqmp_pm_release_node(const u32 node)
> > > }
> > > EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
> > >
> > > +/**
> > > + * zynqmp_pm_force_powerdown - PM call to request for another PU or
> > subsystem to
> > > + * be powered down forcefully
> > > + * @target: Node ID of the targeted PU or subsystem
> > > + * @ack: Flag to specify whether acknowledge is requested
> > > + *
> > > + * Return: status, either success or error+reason
> > > + */
> > > +int zynqmp_pm_force_powerdown(const u32 target,
> >
> > If the target is really the node id, why not calling it "node", the same
> > way as below?
> [Ben Levinsky] good point. Will change to "target" in v9
> >
> >
> > > + const enum zynqmp_pm_request_ack ack)
> > > +{
> > > + return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, target, ack,
> > 0, 0, NULL);
> > > +}
> > > +EXPORT_SYMBOL_GPL(zynqmp_pm_force_powerdown);
> > > +
> > > +/**
> > > + * zynqmp_pm_request_wakeup - PM call to wake up selected master or
> > subsystem
> > > + * @node: Node ID of the master or subsystem
> > > + * @set_addr: Specifies whether the address argument is relevant
> > > + * @address: Address from which to resume when woken up
> > > + * @ack: Flag to specify whether acknowledge requested
> > > + *
> > > + * Return: status, either success or error+reason
> > > + */
> > > +int zynqmp_pm_request_wakeup(const u32 node,
> > > + const bool set_addr,
> > > + const u64 address,
> > > + const enum zynqmp_pm_request_ack ack)
> > > +{
> > > + /* set_addr flag is encoded into 1st bit of address */
> > > + return zynqmp_pm_invoke_fn(PM_REQUEST_WAKEUP, node, address
> > | set_addr,
> > > + address >> 32, ack, NULL);
> > > +}
> > > +EXPORT_SYMBOL_GPL(zynqmp_pm_request_wakeup);
> > > +
> > > /**
> > > * zynqmp_pm_set_requirement() - PM call to set requirement for PM
> > slaves
> > > * @node: Node ID of the slave
> > > diff --git a/include/linux/firmware/xlnx-zynqmp.h
> > b/include/linux/firmware/xlnx-zynqmp.h
> > > index bb347dfe4ba4..4d83a7d69c4c 100644
> > > --- a/include/linux/firmware/xlnx-zynqmp.h
> > > +++ b/include/linux/firmware/xlnx-zynqmp.h
> > > @@ -64,6 +64,8 @@
> > >
> > > enum pm_api_id {
> > > PM_GET_API_VERSION = 1,
> > > + PM_FORCE_POWERDOWN = 8,
> > > + PM_REQUEST_WAKEUP = 10,
> > > PM_SYSTEM_SHUTDOWN = 12,
> > > PM_REQUEST_NODE = 13,
> > > PM_RELEASE_NODE,
> > > @@ -376,6 +378,12 @@ int zynqmp_pm_write_pggs(u32 index, u32
> value);
> > > int zynqmp_pm_read_pggs(u32 index, u32 *value);
> > > int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
> > > int zynqmp_pm_set_boot_health_status(u32 value);
> > > +int zynqmp_pm_force_powerdown(const u32 target,
> > > + const enum zynqmp_pm_request_ack ack);
> > > +int zynqmp_pm_request_wakeup(const u32 node,
> > > + const bool set_addr,
> > > + const u64 address,
> > > + const enum zynqmp_pm_request_ack ack);
> > > #else
> > > static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
> > > {
> > > @@ -526,6 +534,20 @@ static inline int
> > zynqmp_pm_set_boot_health_status(u32 value)
> > > {
> > > return -ENODEV;
> > > }
> > > +
> > > +static inline int zynqmp_pm_force_powerdown(const u32 target,
> > > + const enum zynqmp_pm_request_ack ack)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > +
> > > +static inline int zynqmp_pm_request_wakeup(const u32 node,
> > > + const bool set_addr,
> > > + const u64 address,
> > > + const enum zynqmp_pm_request_ack ack)
> >
> > code style
[Ben Levinsky] for this, the argument goes over 80 chars if aligned like the others. With that in mind for style, is it better to have the set_addr and address args aligned with ack or to push ack to the right but have the >80 chars style issue?
Thanks
Ben
> >
> [Ben Levinsky] will fix this in v9
> >
> > > +{
> > > + return -ENODEV;
> > > +}
> > > #endif
> > >
> > > #endif /* __FIRMWARE_ZYNQMP_H__ */
> > > --
> > > 2.17.1
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > >
