Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-03-21 Thread Ben Levinsky
Hi Mathieu

-Original Message-
From: Mathieu Poirier 
Date: Wednesday, March 17, 2021 at 9:27 AM
To: Ben Levinsky 
Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek , "Ed T. Mooring" 
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

On Mon, Mar 15, 2021 at 09:32:40PM +, Ben Levinsky wrote:
> 
> 
> -Original Message-
> From: Mathieu Poirier 
> Date: Monday, March 15, 2021 at 10:37 AM
> To: Ben Levinsky 
> Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek , "Ed T. Mooring" 
> Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc 
driver
> 
> On Thu, Mar 11, 2021 at 11:49:13PM +, Ben Levinsky wrote:
> > Hi Mathieu
> > 
    > > -Original Message-
> > From: Mathieu Poirier 
> > Date: Tuesday, March 9, 2021 at 8:53 AM
> > To: Ben Levinsky 
> > Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek 
> > Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 
remoteproc driver
> > 
> > [...]
> > 
> > > +
> > > +/**
> > > + * zynqmp_r5_probe - Probes ZynqMP R5 processor device node
> > > + *  this is called for each individual R5 
core to
> > > + *  set up mailbox, Xilinx platform manager 
unique ID,
> > > + *  add to rproc core
> > > + *
> > > + * @pdev: domain platform device for current R5 core
> > > + * @node: pointer of the device node for current R5 core
> > > + * @rpu_mode: mode to configure RPU, split or lockstep
> > > + *
> > > + * Return: 0 for success, negative value for failure.
> > > + */
> > > +static struct zynqmp_r5_rproc *zynqmp_r5_probe(struct 
platform_device *pdev,
> > > +struct 
device_node *node,
> > > +enum 
rpu_oper_mode rpu_mode)
> > > +{
> > > + int ret, num_banks;
> > > + struct device *dev = >dev;
> > > + struct rproc *rproc_ptr;
> > > + struct zynqmp_r5_rproc *z_rproc;
> > > + struct device_node *r5_node;
> > > +
> > > + /* Allocate remoteproc instance */
> > > + rproc_ptr = devm_rproc_alloc(dev, dev_name(dev), 
_r5_rproc_ops,
> > > +  NULL, sizeof(struct 
zynqmp_r5_rproc));
> > > + if (!rproc_ptr) {
> > > + ret = -ENOMEM;
> > > + goto error;
> > > + }
> > > +
> > > + rproc_ptr->auto_boot = false;
> > > + z_rproc = rproc_ptr->priv;
> > > + z_rproc->rproc = rproc_ptr;
> > > + r5_node = z_rproc->rproc->dev.parent->of_node;
> > > +
> > > + /* Set up DMA mask */
> > > + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> > > + if (ret)
> > > + goto error;
> > > +
> > > + /* Get R5 power domain node */
> > > + ret = of_property_read_u32(node, "power-domain", 
_rproc->pnode_id);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + ret = r5_set_mode(z_rproc, rpu_mode);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + if (of_property_read_bool(node, "mboxes")) {
> > > + ret = zynqmp_r5_setup_mbox(z_rproc, node);
> > > + if (ret)
  

Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-03-19 Thread Ben Levinsky


-Original Message-
From: Mathieu Poirier 
Date: Wednesday, March 17, 2021 at 9:27 AM
To: Ben Levinsky 
Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek , "Ed T. Mooring" 
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

On Mon, Mar 15, 2021 at 09:32:40PM +, Ben Levinsky wrote:
> 
> 
> -Original Message-
> From: Mathieu Poirier 
> Date: Monday, March 15, 2021 at 10:37 AM
> To: Ben Levinsky 
> Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek , "Ed T. Mooring" 
> Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc 
driver
> 
> On Thu, Mar 11, 2021 at 11:49:13PM +, Ben Levinsky wrote:
> > Hi Mathieu
> > 
    > > -Original Message-
> > From: Mathieu Poirier 
> > Date: Tuesday, March 9, 2021 at 8:53 AM
> > To: Ben Levinsky 
> > Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek 
> > Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 
remoteproc driver
> > 
> > [...]
> > 
> > > +
> > > +/**
> > > + * zynqmp_r5_probe - Probes ZynqMP R5 processor device node
> > > + *  this is called for each individual R5 
core to
> > > + *  set up mailbox, Xilinx platform manager 
unique ID,
> > > + *  add to rproc core
> > > + *
> > > + * @pdev: domain platform device for current R5 core
> > > + * @node: pointer of the device node for current R5 core
> > > + * @rpu_mode: mode to configure RPU, split or lockstep
> > > + *
> > > + * Return: 0 for success, negative value for failure.
> > > + */
> > > +static struct zynqmp_r5_rproc *zynqmp_r5_probe(struct 
platform_device *pdev,
> > > +struct 
device_node *node,
> > > +enum 
rpu_oper_mode rpu_mode)
> > > +{
> > > + int ret, num_banks;
> > > + struct device *dev = >dev;
> > > + struct rproc *rproc_ptr;
> > > + struct zynqmp_r5_rproc *z_rproc;
> > > + struct device_node *r5_node;
> > > +
> > > + /* Allocate remoteproc instance */
> > > + rproc_ptr = devm_rproc_alloc(dev, dev_name(dev), 
_r5_rproc_ops,
> > > +  NULL, sizeof(struct 
zynqmp_r5_rproc));
> > > + if (!rproc_ptr) {
> > > + ret = -ENOMEM;
> > > + goto error;
> > > + }
> > > +
> > > + rproc_ptr->auto_boot = false;
> > > + z_rproc = rproc_ptr->priv;
> > > + z_rproc->rproc = rproc_ptr;
> > > + r5_node = z_rproc->rproc->dev.parent->of_node;
> > > +
> > > + /* Set up DMA mask */
> > > + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> > > + if (ret)
> > > + goto error;
> > > +
> > > + /* Get R5 power domain node */
> > > + ret = of_property_read_u32(node, "power-domain", 
_rproc->pnode_id);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + ret = r5_set_mode(z_rproc, rpu_mode);
> > > + if (ret)
> > > + goto error;
> > > +
> > > + if (of_property_read_bool(node, "mboxes")) {
> > > + ret = zynqmp_r5_setup_mbox(z_rproc, node);
> > > + if (ret)
>

Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-03-15 Thread Ben Levinsky


-Original Message-
From: Mathieu Poirier 
Date: Monday, March 15, 2021 at 10:26 AM
To: Ben Levinsky 
Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek , "Ed T. Mooring" 
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

> > +
> > +static void zynqmp_r5_cleanup_mbox(struct zynqmp_r5_rproc *z_rproc)
> > +{
> > +   mbox_free_channel(z_rproc->tx_chan);
> > +   mbox_free_channel(z_rproc->rx_chan);
> > +}
> > +
> > +/**
> > + * zynqmp_r5_probe - Probes ZynqMP R5 processor device node
> > + *this is called for each individual R5 core to
> > + *set up mailbox, Xilinx platform manager unique 
ID,
> > + *add to rproc core
> 
> The above has changed since last time, which makes it harder for me to
> review your work.  From hereon please change only the things I point 
out so that
> we keep the same goal posts from one revision to the other.
> 
> The tabulation needs to be fixed:  
> 
> * zynqmp_r5_probe - Probes ZynqMP R5 processor device node
> *
> * This is called for each individual R5 core to set up 
mailbox, Xilinx
> * platform manager unique ID, add to rproc core.
> 
> The description is also broken.
> 
> [Ben] Ok. How is the following:
> /**   
 
>  * zynqmp_r5_probe - Probes ZynqMP R5 processor device node   
 
>  *
 
>  * This is called for each individual R5 core to set up mailbox, Xilinx   
 
>  * platform manager unique ID, collect SRAM information and wire in   
 
>  * driver-specific data to to rproc core. 
 
>  *
 
>  * @pdev: domain platform device for current R5 core  
 
>  * @node: pointer of the device node for current R5 core  
 
>  * @rpu_mode: mode to configure RPU, split or lockstep
 
>  *
 
>  * Return: 0 for success, negative value for failure. 
 

Much better

>  */   
 
> static struct zynqmp_r5_rproc *zynqmp_r5_probe(struct platform_device 
*pdev,   
>struct device_node *node,  
 
>enum rpu_oper_mode 
rpu_mode) 
> 
> 
> > + *
> > + * @pdev: domain platform device for current R5 core
> > + * @node: pointer of the device node for current R5 core
> > + * @rpu_mode: mode to configure RPU, split or lockstep
> > + *
> > + * Return: 0 for success, negative value for failure.
> > + */
> > +static struct zynqmp_r5_rproc *zynqmp_r5_probe(struct 
platform_device *pdev,
> > +  struct device_node *node,
> > +  enum rpu_oper_mode 
rpu_mode)
> > +{
> > +   int ret, num_banks;
> > +   struct device *dev = >dev;
> > +   struct rproc *rproc_ptr;
> > +   struct zynqmp_r5_rproc *z_rproc;
> > +   struct device_node *r5_node;
> > +
> > +   /* Allocate remoteproc instance */
> > +   rproc_ptr = devm_rproc_alloc(dev, dev_name(dev), 
_r5_rproc_ops,
> > +NULL, sizeof(struct 
zynqmp_r5_rproc));
> > +   if (!rproc_ptr) {
> > +   ret = -ENOMEM;
> > +   goto error;
> > +   }
> > +
> > +   rproc_ptr->auto_boot = false;
> > +   z_rproc = rproc_ptr->priv;
> > +   z_rproc->rproc = rproc_ptr;
> > +   r5_node = z_rproc->rproc->dev.parent->of_node;
> > +
> > +   /* Set up DMA mask */
> > +   ret = d

Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-03-15 Thread Ben Levinsky


-Original Message-
From: Mathieu Poirier 
Date: Monday, March 15, 2021 at 10:37 AM
To: Ben Levinsky 
Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek , "Ed T. Mooring" 
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

On Thu, Mar 11, 2021 at 11:49:13PM +, Ben Levinsky wrote:
> Hi Mathieu
> 
> -Original Message-
> From: Mathieu Poirier 
> Date: Tuesday, March 9, 2021 at 8:53 AM
> To: Ben Levinsky 
> Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek 
> Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc 
driver
> 
> [...]
> 
> > +
> > +/**
> > + * zynqmp_r5_probe - Probes ZynqMP R5 processor device node
> > + *this is called for each individual R5 core to
> > + *set up mailbox, Xilinx platform manager unique 
ID,
> > + *add to rproc core
> > + *
> > + * @pdev: domain platform device for current R5 core
> > + * @node: pointer of the device node for current R5 core
> > + * @rpu_mode: mode to configure RPU, split or lockstep
> > + *
> > + * Return: 0 for success, negative value for failure.
> > + */
> > +static struct zynqmp_r5_rproc *zynqmp_r5_probe(struct 
platform_device *pdev,
> > +  struct device_node *node,
> > +  enum rpu_oper_mode 
rpu_mode)
> > +{
> > +   int ret, num_banks;
> > +   struct device *dev = >dev;
> > +   struct rproc *rproc_ptr;
> > +   struct zynqmp_r5_rproc *z_rproc;
> > +   struct device_node *r5_node;
> > +
> > +   /* Allocate remoteproc instance */
> > +   rproc_ptr = devm_rproc_alloc(dev, dev_name(dev), 
_r5_rproc_ops,
> > +NULL, sizeof(struct 
zynqmp_r5_rproc));
> > +   if (!rproc_ptr) {
> > +   ret = -ENOMEM;
> > +   goto error;
> > +   }
> > +
> > +   rproc_ptr->auto_boot = false;
> > +   z_rproc = rproc_ptr->priv;
> > +   z_rproc->rproc = rproc_ptr;
> > +   r5_node = z_rproc->rproc->dev.parent->of_node;
> > +
> > +   /* Set up DMA mask */
> > +   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> > +   if (ret)
> > +   goto error;
> > +
> > +   /* Get R5 power domain node */
> > +   ret = of_property_read_u32(node, "power-domain", 
_rproc->pnode_id);
> > +   if (ret)
> > +   goto error;
> > +
> > +   ret = r5_set_mode(z_rproc, rpu_mode);
> > +   if (ret)
> > +   goto error;
> > +
> > +   if (of_property_read_bool(node, "mboxes")) {
> > +   ret = zynqmp_r5_setup_mbox(z_rproc, node);
> > +   if (ret)
> > +   goto error;
> > +   }
> > +
> > +   /* go through TCM banks for r5 node */
> > +   num_banks = of_count_phandle_with_args(r5_node, BANK_LIST_PROP, 
NULL);
> > +   if (num_banks <= 0) {
> > +   dev_err(dev, "need to specify TCM banks\n");
> > +   ret = -EINVAL;
> > +   goto error;
> > +   }
> > +
> > +   if (num_banks > NUM_SRAMS) {
> > +   dev_err(dev, "max number of srams is %d. given: %d 
\r\n",
> > +   NUM_SRAMS, num_banks);
> > +   ret = -EINVAL;
> > +   goto error;
> > +   }
> > +
> > +   /* construct collection of srams used by the current R5 core */
> > +   for (; num_banks; num_banks--) {
> > +   struct resource rsc;
> > +   struct device_node *dt_node;
> > +   resource_size_t size;
> > +   int i;
> > +
> > +   d

Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-03-11 Thread Ben Levinsky
Hi Mathieu

-Original Message-
From: Mathieu Poirier 
Date: Tuesday, March 9, 2021 at 8:53 AM
To: Ben Levinsky 
Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek 
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

[...]

> +
> +/**
> + * zynqmp_r5_probe - Probes ZynqMP R5 processor device node
> + *  this is called for each individual R5 core to
> + *  set up mailbox, Xilinx platform manager unique 
ID,
> + *  add to rproc core
> + *
> + * @pdev: domain platform device for current R5 core
> + * @node: pointer of the device node for current R5 core
> + * @rpu_mode: mode to configure RPU, split or lockstep
> + *
> + * Return: 0 for success, negative value for failure.
> + */
> +static struct zynqmp_r5_rproc *zynqmp_r5_probe(struct platform_device 
*pdev,
> +struct device_node *node,
> +enum rpu_oper_mode rpu_mode)
> +{
> + int ret, num_banks;
> + struct device *dev = >dev;
> + struct rproc *rproc_ptr;
> + struct zynqmp_r5_rproc *z_rproc;
> + struct device_node *r5_node;
> +
> + /* Allocate remoteproc instance */
> + rproc_ptr = devm_rproc_alloc(dev, dev_name(dev), _r5_rproc_ops,
> +  NULL, sizeof(struct zynqmp_r5_rproc));
> + if (!rproc_ptr) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + rproc_ptr->auto_boot = false;
> + z_rproc = rproc_ptr->priv;
> + z_rproc->rproc = rproc_ptr;
> + r5_node = z_rproc->rproc->dev.parent->of_node;
> +
> + /* Set up DMA mask */
> + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto error;
> +
> + /* Get R5 power domain node */
> + ret = of_property_read_u32(node, "power-domain", _rproc->pnode_id);
> + if (ret)
> + goto error;
> +
> + ret = r5_set_mode(z_rproc, rpu_mode);
> + if (ret)
> + goto error;
> +
> + if (of_property_read_bool(node, "mboxes")) {
> + ret = zynqmp_r5_setup_mbox(z_rproc, node);
> + if (ret)
> + goto error;
> + }
> +
> + /* go through TCM banks for r5 node */
> + num_banks = of_count_phandle_with_args(r5_node, BANK_LIST_PROP, NULL);
> + if (num_banks <= 0) {
> + dev_err(dev, "need to specify TCM banks\n");
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + if (num_banks > NUM_SRAMS) {
> + dev_err(dev, "max number of srams is %d. given: %d \r\n",
> + NUM_SRAMS, num_banks);
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + /* construct collection of srams used by the current R5 core */
> + for (; num_banks; num_banks--) {
> + struct resource rsc;
> + struct device_node *dt_node;
> + resource_size_t size;
> + int i;
> +
> + dt_node = of_parse_phandle(r5_node, BANK_LIST_PROP, i);

Variable @i is not initialised but it is used as an index to retrieve a 
handle
to the sram banks.  That code _should_ have failed frequently or at least 
have
yielded abnormal results often enough to be noticed.  Why wasn't it the 
case?

I will stop here for the moment.

[Ben]
Yes this should be initialized. The reason this got through is that as i 
defaults to 0 and the 0th bank housed the required data. the case where SRAMS 
that can be written to, 0xFFE2 in this case of split mode and on R5-0, was 
not caught.

Instead of i I will use 

sram_node = of_parse_phandle(node, BANK_LIST_PROP,  
 num_banks - 1); 


sram_node is the var name given in the function called by probe to collect the 
SRAM information.



If there is other feedback please let me know

Thanks
Ben


> + if (!dt_node) {
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + ret = of_address_to_resource(dt_node, 0, );
> + if (ret < 0) {
> + of_node_put(dt_node);
> + goto error;
> + }
> +
> + of_node_put(dt_node);
> + size = resource_size();
> +

Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-03-11 Thread Ben Levinsky
Hi Mathieu 

Thanks for the feedback. I responded inline

-Original Message-
From: Mathieu Poirier 
Date: Monday, March 8, 2021 at 11:00 AM
To: Ben Levinsky 
Cc: "devicet...@vger.kernel.org" , 
"linux-remotep...@vger.kernel.org" , 
"linux-kernel@vger.kernel.org" , 
"linux-arm-ker...@lists.infradead.org" , 
Michal Simek 
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

On Tue, Feb 23, 2021 at 07:44:47AM -0800, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remoteproc driver, we can boot the R5 sub-system in two different
> configurations -
>   * Split
>   * Lockstep
> 
> The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> Platform Management Unit that handles the R5 configuration, memory access
> and R5 lifecycle management. The interface to this manager is done in this
> driver via zynqmp_pm_* function calls.
> 
> Signed-off-by: Wendy Liang 
> Signed-off-by: Michal Simek 
> Signed-off-by: Ed Mooring 
> Signed-off-by: Jason Wu 
> Signed-off-by: Ben Levinsky 
> ---
>  drivers/remoteproc/Kconfig|   8 +
>  drivers/remoteproc/Makefile   |   1 +
>  drivers/remoteproc/zynqmp_r5_remoteproc.c | 954 ++
>  3 files changed, 963 insertions(+)
>  create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index c6659dfea7c7..c2fe54b1d94f 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
> It's safe to say N here if you're not interested in utilizing
> the DSP slave processors.
>  
> +config ZYNQMP_R5_REMOTEPROC
> + tristate "ZynqMP R5 remoteproc support"
> + depends on PM && ARCH_ZYNQMP
> + select RPMSG_VIRTIO
> + select ZYNQMP_IPI_MBOX
> + help
> +   Say y or m here to support ZynqMP R5 remote processors via the remote
> +   processor framework.
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 3dfa28e6c701..ef1abff654c2 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC) += 
st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
> +obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC)   += zynqmp_r5_remoteproc.o
> diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
> new file mode 100644
> index ..4bcff2daceaf
> --- /dev/null
> +++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
> @@ -0,0 +1,954 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Zynq R5 Remote Processor driver
> + *
> + * Based on origin OMAP and Zynq Remote Processor driver
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "remoteproc_internal.h"
> +
> +#define MAX_RPROCS   2 /* Support up to 2 RPU */
> +#define MAX_MEM_PNODES   4 /* Max power nodes for one RPU memory 
instance */
> +
> +#define BANK_LIST_PROP   "sram"
> +#define DDR_LIST_PROP"memory-region"
> +
> +/* IPI buffer MAX length */
> +#define IPI_BUF_LEN_MAX  32U
> +/* RX mailbox client buffer max length */
> +#define RX_MBOX_CLIENT_BUF_MAX   (IPI_BUF_LEN_MAX + \
> +  sizeof(struct zynqmp_ipi_message))
> +
> +/*
> + * Map each Xilinx on-chip SRAM  Bank address to their own respective
> + * pm_node_id.
> + *
> + * size can differ based on R5 cluster configuration so record from
> + * device tree in zynqmp_r5_probe.
> + */
> +struct sram_addr_data {
> + phys_addr_t addr;
> + enum pm_node_id id;
> + resource_size_t size;
> +};
> +
> +#define NUM_SRAMS 4U
> +static const struct sram_addr_data zynqmp_banks[NUM_SRAMS] = {
> + {0xffe0UL, NODE_TCM_0_A, 0},
> + {0xffe2UL, NODE_TCM_0_B, 0},
   

[PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-02-23 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remoteproc driver, we can boot the R5 sub-system in two different
configurations -
* Split
* Lockstep

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 954 ++
 3 files changed, 963 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..4bcff2daceaf
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,954 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "sram"
+#define DDR_LIST_PROP  "memory-region"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/*
+ * Map each Xilinx on-chip SRAM  Bank address to their own respective
+ * pm_node_id.
+ *
+ * size can differ based on R5 cluster configuration so record from
+ * device tree in zynqmp_r5_probe.
+ */
+struct sram_addr_data {
+   phys_addr_t addr;
+   enum pm_node_id id;
+   resource_size_t size;
+};
+
+#define NUM_SRAMS 4U
+static const struct sram_addr_data zynqmp_banks[NUM_SRAMS] = {
+   {0xffe0UL, NODE_TCM_0_A, 0},
+   {0xffe2UL, NODE_TCM_0_B, 0},
+   {0xffe9UL, NODE_TCM_1_A, 0},
+   {0xffebUL, NODE_TCM_1_B, 0},
+};
+
+/**
+ * struct zynqmp_r5_rproc - ZynqMP R5 core structure
+ *
+ * @rx_mc_buf: rx mailbox client buffer to save the rx message
+ * @srams : srams Xilinx mgmt IDs for srams that will be used by R5 core.
+ * @tx_mc: tx mailbox client
+ * @rx_mc: rx mailbox client
+ * @mbox_work: mbox_work for the RPU remoteproc
+ * @tx_mc_skbs: socket buffers for tx mailbox client
+ * @rproc: rproc handle
+ * @tx_chan: tx mailbox channel
+ * @rx_chan: rx mailbox channel
+ * @pnode_id: RPU CPU power domain id
+ * @elem: linked list item
+ */
+struct zynqmp_r5_rproc {
+   unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
+   struct sram_addr_data srams[NUM_SRAMS];
+   struct mbox_client tx_mc;
+   struct mbox_client rx_mc;
+   struct work_struct mbox_work;
+   struct sk_buff_head tx_mc_skbs;
+   struct rproc *rproc;
+   struct mbox_chan *tx_chan;
+   struct mbox_chan *rx_chan;
+   u32 pnode_id;
+   struct list_head elem;
+};
+
+/*
+ * r5_set_mode
+ * @z_rproc: Remote processor private data
+ * @rpu_mode: mode specified by device tree to configure the RPU to
+ *
+ * set RPU operation mode
+ *
+ * Return: 0 for success, negative value for failure
+ */
+static int r5_set_mode(struct zynqmp_r5_rproc *z_rproc,
+  enum rpu_oper_mode rpu_mode)
+{
+   enum rpu_tcm_comb t

[PATCH v26 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2021-02-23 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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 e4044cae0713..2d5c644cb570 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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,
@@ -380,6 +383,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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)
 {
@@ -530,6 +539,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v26 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2021-02-23 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration and TCM Nodes for
later use via request_node and release_node

Signed-off-by: Ben Levinsky 
---
 include/linux/firmware/xlnx-zynqmp.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..e4044cae0713 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
@@ -273,6 +292,10 @@ enum zynqmp_pm_request_ack {
 };
 
 enum pm_node_id {
+   NODE_TCM_0_A = 15,
+   NODE_TCM_0_B,
+   NODE_TCM_1_A,
+   NODE_TCM_1_B,
NODE_SD_0 = 39,
NODE_SD_1,
 };
-- 
2.17.1



[PATCH v26 0/5] Add initial zynqmp R5 remoteproc driver

2021-02-23 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in two different
configurations -
* Split
* Lockstep

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

v26:
- add prepare and unprepare to handle Xilinx platform management's
  request_node and release node using each core's list of srams
  that is constructed in each core's zynqmp_r5_probe.
- add new field sram to zynqmp_r5_rproc to store each core's srams
  being used as described in device tree. This helps to reduce unneeded looping
  of the sram prop in device tree. As now only zynqmp_r5_probe has to parse
  and validate each core's sram property. The ensuing prepare, unprepare
  and parse_fw logic are now much simpler.
- similarly add 'size' field to struct sram_addr_data to simplify
  prepare, unprepare and parse_fw.

Previous version:
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=412083


Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 
 drivers/firmware/xilinx/zynqmp.c  |  96 ++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 954 ++
 include/linux/firmware/xlnx-zynqmp.h  |  64 ++
 6 files changed, 1356 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v26 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2021-02-23 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 ++
 1 file changed, 223 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..b9412c2def7b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipsets.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  $nodename:
+pattern: "^r5fss(@.*)?"
+
+  compatible:
+enum:
+  - xlnx,zynqmp-r5-remoteproc
+
+  reg:
+items:
+  - description: Address and Size of Xilinx RPU Configuration register
+
+  "#address-cells":
+const: 2
+
+  "#size-cells":
+const: 2
+
+  ranges: true
+
+# Optional properties:
+# 
+  xlnx,cluster-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configuration Mode for the Dual R5F cores within the R5F cluster.
+  Should be either a value of 1 (LockStep mode) or 0 (Split mode),
+  default is LockStep mode if omitted.
+
+
+#R5F Processor Child Nodes:
+# ==
+
+patternProperties:
+  "^r5f_[a-f0-9]+$":
+type: object
+description: |
+  The R5F Sub-System device node should define one or two R5F child nodes,
+  each node representing a Xilinx instantiation of the Arm Cortex R5F core.
+  There should be one or two child nodes if the R5F is in Split mode and
+  one child node if the R5F is in Lockstep mode.
+
+  In Split mode each R5F core has two associated TCM Banks. R5_0 has
+  TCM Banks 0A and 0B and R5_1 has TCM Banks 1A and 1B.
+
+  In Lockstep mode only one R5F child node should be defined. This one
+  child has access to TCM Banks 0A, 0B, 1A and 1B and any of the four can
+  be included in the child R5F's sram property.
+
+  The example below shows Split mode with two child nodes.
+
+properties:
+  compatible:
+enum:
+  - xilinx,r5f
+
+# The following properties are mandatory for R5F Core0 in both LockStep and 
Split
+# modes, and are mandatory for R5F Core1 _only_ in Split mode.
+
+  memory-region:
+description: |
+  Phandles to the memory nodes to be associated with the
+  The reserved memory nodes should be carveout nodes, and
+  should be defined with a "no-map" property as per the bindings in
+  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+minItems: 1
+maxItems: 6
+items:
+  - description: Region used for dynamic DMA allocations like vrings 
and
+ vring buffers
+  - description: Region reserved for firmware image sections
+additionalItems: true
+
+  power-domain:
+description: |
+  Power node ID that is used to uniquely identify the RPU for Xilinx
+  Power Management.
+maxItems: 1
+
+# Optional properties:
+# 
+# The following properties are optional properties for each of the R5F cores:
+
+  mboxes:
+description: |
+  Standard property to specify a mailbox
+  This property is required only if the rpmsg/virtio functionality
+  is used
+
+   Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+   property
+maxItems: 1
+
+  mbox-names:
+description: |
+  Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+  property
+items:
+  - const: tx
+  - const: rx
+
+  sram:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+minItems: 1
+maxItems: 4
+description: |
+  Phandles to one or more reserved on-chip SRAM regions. The regions
+  should be defined as child nodes of the respective SRAM node, 

[PATCH v26 3/5] firmware: xilinx: Add RPU configuration APIs

2021-02-23 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 2d5c644cb570..22ccac1db9a9 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -389,6 +389,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -553,6 +556,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



RE: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-02-17 Thread Ben Levinsky
1 more for the pnode_id comment

> -Original Message-
> From: Ben Levinsky
> Sent: Wednesday, February 17, 2021 11:12 AM
> To: Mathieu Poirier 
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal Simek
> 
> Subject: RE: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hi Mathieu,
> 
> I worked on this further and had 1 more comment on the prepare/unprepare
> for TCM banks below
> 
> > -Original Message-
> > From: Ben Levinsky
> > Sent: Wednesday, February 17, 2021 8:47 AM
> > To: Mathieu Poirier 
> > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal Simek
> > 
> > Subject: RE: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> > driver
> >
> > Hi Mathieu,
> >
> > Please see my replies to your questions inline
> >
> > Again thanks for the continued review of this set
> >
> > Cheers
> > Ben
> >
> > > -Original Message-
> > > From: Mathieu Poirier 
> > > Sent: Tuesday, February 16, 2021 10:48 AM
> > > To: Ben Levinsky 
> > > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal
> Simek
> > > 
> > > Subject: Re: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5
> remoteproc
> > > driver
> > >
> > > On Sun, Jan 10, 2021 at 06:02:50PM -0800, Ben Levinsky wrote:
> > > > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > > > remotproc driver, we can boot the R5 sub-system in two different
> > > > configurations -
> > > > * Split
> > > > * Lockstep
> > > >
> > > > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > > > Platform Management Unit that handles the R5 configuration, memory
> > > access
> > > > and R5 lifecycle management. The interface to this manager is done in
> this
> > > > driver via zynqmp_pm_* function calls.
> > > >
> > > > Signed-off-by: Wendy Liang 
> > > > Signed-off-by: Michal Simek 
> > > > Signed-off-by: Ed Mooring 
> > > > Signed-off-by: Jason Wu 
> > > > Signed-off-by: Ben Levinsky 
> > > > ---
> > > > v25:
> > > > - reword error message for rpu configuration
> > > > - change char name[15] to 16 chars to have null terminated string
> > > >   in parse_mem_regions()
> > > > - reword comments in tcm_mem_alloc
> > > > - call xilinx platform cleanup in parse_tcm_banks() case of failure
> > > > - check value of mbox_send_message in all instances within this driver
> > > > - indentation in zynqmp_r5_remoteproc driver
> > > > - update style of constructing carveouts to match convention in ST
> > > >   remoteproc drivers. No longer iterate through memory-region property
> > > >   using of_count_phandle_with_args. Instead use of_phandle_iterator
> > > > - use rproc_of_resm_mem_entry_init for vdev0buffer carveout as per
> > > feedback
> > > > - rework loop in zynqmp_r5_pm_request_sram as per feedback
> > > > - fix comment and linebreak in tcm_mem_alloc description
> > > > - add comments and remove extraneous devm_ioremap_wc call in
> > > tcm_mem_alloc
> > > > - in parse_tcm_banks remove check for bank not being available
> > > > - rework order of locals and remove else in zynqmp_r5_rproc_kick
> > > > - document and update logic for zynqmp_r5_parse_fw
> > > > - add dev_dbg output in event_notified_idr_cb if
> > > >   rproc_vq_interrupt(rproc, id) == IRQ_NONE
> > > > - add comment for handle_event_notified mbox_send_message function
> > > call
> > > > - add comment for zynqmp_r5_mb_rx_cb
> > > > - update zynqmp_r5_setup_mbox to match convention of mbox setup in
> > ST
> > > >   remoteproc drivers
> > > > - change return in zynqmp_r5_setup_mbox to use PTR_ERR
> > > > - add zynqmp_r5_cleanup_mbox
> > > > - in zynqmp_r5_probe, reteurn zynqmp_r5_rproc instead of taking in as
> > arg.
> > > > - in zynqmp_r5_probe use return of PTR_ERR and use
> > > zynqmp_r5_cleanup_mbox
> > > > - in zynqmp_r5_remoteproc_probe update use return value of
> >

RE: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-02-17 Thread Ben Levinsky
Hi Mathieu,

I worked on this further and had 1 more comment on the prepare/unprepare for 
TCM banks below

> -Original Message-
> From: Ben Levinsky
> Sent: Wednesday, February 17, 2021 8:47 AM
> To: Mathieu Poirier 
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal Simek
> 
> Subject: RE: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hi Mathieu,
> 
> Please see my replies to your questions inline
> 
> Again thanks for the continued review of this set
> 
> Cheers
> Ben
> 
> > -Original Message-
> > From: Mathieu Poirier 
> > Sent: Tuesday, February 16, 2021 10:48 AM
> > To: Ben Levinsky 
> > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal Simek
> > 
> > Subject: Re: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> > driver
> >
> > On Sun, Jan 10, 2021 at 06:02:50PM -0800, Ben Levinsky wrote:
> > > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > > remotproc driver, we can boot the R5 sub-system in two different
> > > configurations -
> > >   * Split
> > >   * Lockstep
> > >
> > > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > > Platform Management Unit that handles the R5 configuration, memory
> > access
> > > and R5 lifecycle management. The interface to this manager is done in this
> > > driver via zynqmp_pm_* function calls.
> > >
> > > Signed-off-by: Wendy Liang 
> > > Signed-off-by: Michal Simek 
> > > Signed-off-by: Ed Mooring 
> > > Signed-off-by: Jason Wu 
> > > Signed-off-by: Ben Levinsky 
> > > ---
> > > v25:
> > > - reword error message for rpu configuration
> > > - change char name[15] to 16 chars to have null terminated string
> > >   in parse_mem_regions()
> > > - reword comments in tcm_mem_alloc
> > > - call xilinx platform cleanup in parse_tcm_banks() case of failure
> > > - check value of mbox_send_message in all instances within this driver
> > > - indentation in zynqmp_r5_remoteproc driver
> > > - update style of constructing carveouts to match convention in ST
> > >   remoteproc drivers. No longer iterate through memory-region property
> > >   using of_count_phandle_with_args. Instead use of_phandle_iterator
> > > - use rproc_of_resm_mem_entry_init for vdev0buffer carveout as per
> > feedback
> > > - rework loop in zynqmp_r5_pm_request_sram as per feedback
> > > - fix comment and linebreak in tcm_mem_alloc description
> > > - add comments and remove extraneous devm_ioremap_wc call in
> > tcm_mem_alloc
> > > - in parse_tcm_banks remove check for bank not being available
> > > - rework order of locals and remove else in zynqmp_r5_rproc_kick
> > > - document and update logic for zynqmp_r5_parse_fw
> > > - add dev_dbg output in event_notified_idr_cb if
> > >   rproc_vq_interrupt(rproc, id) == IRQ_NONE
> > > - add comment for handle_event_notified mbox_send_message function
> > call
> > > - add comment for zynqmp_r5_mb_rx_cb
> > > - update zynqmp_r5_setup_mbox to match convention of mbox setup in
> ST
> > >   remoteproc drivers
> > > - change return in zynqmp_r5_setup_mbox to use PTR_ERR
> > > - add zynqmp_r5_cleanup_mbox
> > > - in zynqmp_r5_probe, reteurn zynqmp_r5_rproc instead of taking in as
> arg.
> > > - in zynqmp_r5_probe use return of PTR_ERR and use
> > zynqmp_r5_cleanup_mbox
> > > - in zynqmp_r5_remoteproc_probe update use return value of
> > zynqmp_r5_probe as
> > >   either zynqmp_r5_rproc* or PTR_ERR
> > > - update loop that cleans up cluster and mboxes in
> > zynqmp_r5_remoteproc_probe
> > > - update loop that cleans up cluster and mboxes in
> > zynqmp_r5_remoteproc_remove
> > > ---
> > >  drivers/remoteproc/Kconfig|   8 +
> > >  drivers/remoteproc/Makefile   |   1 +
> > >  drivers/remoteproc/zynqmp_r5_remoteproc.c | 898
> > ++
> > >  3 files changed, 907 insertions(+)
> > >  create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c
> > >
> > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > > index c6659dfea7c7..c2fe54b1d94f 100644
> > > --- a/drivers/remoteproc/Kconfig
> > > +++ b/drivers/r

RE: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-02-17 Thread Ben Levinsky
Hi Mathieu,

Please see my replies to your questions inline

Again thanks for the continued review of this set

Cheers
Ben

> -Original Message-
> From: Mathieu Poirier 
> Sent: Tuesday, February 16, 2021 10:48 AM
> To: Ben Levinsky 
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Michal Simek
> 
> Subject: Re: [PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> On Sun, Jan 10, 2021 at 06:02:50PM -0800, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in two different
> > configurations -
> > * Split
> > * Lockstep
> >
> > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > Platform Management Unit that handles the R5 configuration, memory
> access
> > and R5 lifecycle management. The interface to this manager is done in this
> > driver via zynqmp_pm_* function calls.
> >
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ed Mooring 
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Ben Levinsky 
> > ---
> > v25:
> > - reword error message for rpu configuration
> > - change char name[15] to 16 chars to have null terminated string
> >   in parse_mem_regions()
> > - reword comments in tcm_mem_alloc
> > - call xilinx platform cleanup in parse_tcm_banks() case of failure
> > - check value of mbox_send_message in all instances within this driver
> > - indentation in zynqmp_r5_remoteproc driver
> > - update style of constructing carveouts to match convention in ST
> >   remoteproc drivers. No longer iterate through memory-region property
> >   using of_count_phandle_with_args. Instead use of_phandle_iterator
> > - use rproc_of_resm_mem_entry_init for vdev0buffer carveout as per
> feedback
> > - rework loop in zynqmp_r5_pm_request_sram as per feedback
> > - fix comment and linebreak in tcm_mem_alloc description
> > - add comments and remove extraneous devm_ioremap_wc call in
> tcm_mem_alloc
> > - in parse_tcm_banks remove check for bank not being available
> > - rework order of locals and remove else in zynqmp_r5_rproc_kick
> > - document and update logic for zynqmp_r5_parse_fw
> > - add dev_dbg output in event_notified_idr_cb if
> >   rproc_vq_interrupt(rproc, id) == IRQ_NONE
> > - add comment for handle_event_notified mbox_send_message function
> call
> > - add comment for zynqmp_r5_mb_rx_cb
> > - update zynqmp_r5_setup_mbox to match convention of mbox setup in ST
> >   remoteproc drivers
> > - change return in zynqmp_r5_setup_mbox to use PTR_ERR
> > - add zynqmp_r5_cleanup_mbox
> > - in zynqmp_r5_probe, reteurn zynqmp_r5_rproc instead of taking in as arg.
> > - in zynqmp_r5_probe use return of PTR_ERR and use
> zynqmp_r5_cleanup_mbox
> > - in zynqmp_r5_remoteproc_probe update use return value of
> zynqmp_r5_probe as
> >   either zynqmp_r5_rproc* or PTR_ERR
> > - update loop that cleans up cluster and mboxes in
> zynqmp_r5_remoteproc_probe
> > - update loop that cleans up cluster and mboxes in
> zynqmp_r5_remoteproc_remove
> > ---
> >  drivers/remoteproc/Kconfig|   8 +
> >  drivers/remoteproc/Makefile   |   1 +
> >  drivers/remoteproc/zynqmp_r5_remoteproc.c | 898
> ++
> >  3 files changed, 907 insertions(+)
> >  create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index c6659dfea7c7..c2fe54b1d94f 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
> >   It's safe to say N here if you're not interested in utilizing
> >   the DSP slave processors.
> >
> > +config ZYNQMP_R5_REMOTEPROC
> > +   tristate "ZynqMP R5 remoteproc support"
> > +   depends on PM && ARCH_ZYNQMP
> > +   select RPMSG_VIRTIO
> > +   select ZYNQMP_IPI_MBOX
> > +   help
> > + Say y or m here to support ZynqMP R5 remote processors via the
> remote
> > + processor framework.
> >  endif # REMOTEPROC
> >
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 3dfa28e6c701..ef1abff654c2 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   +=
>

[PATCH v25 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2021-01-10 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in two different
configurations -
* Split
* Lockstep

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
v25:
- reword error message for rpu configuration
- change char name[15] to 16 chars to have null terminated string
  in parse_mem_regions()
- reword comments in tcm_mem_alloc
- call xilinx platform cleanup in parse_tcm_banks() case of failure
- check value of mbox_send_message in all instances within this driver 
- indentation in zynqmp_r5_remoteproc driver
- update style of constructing carveouts to match convention in ST
  remoteproc drivers. No longer iterate through memory-region property
  using of_count_phandle_with_args. Instead use of_phandle_iterator
- use rproc_of_resm_mem_entry_init for vdev0buffer carveout as per feedback
- rework loop in zynqmp_r5_pm_request_sram as per feedback
- fix comment and linebreak in tcm_mem_alloc description
- add comments and remove extraneous devm_ioremap_wc call in tcm_mem_alloc
- in parse_tcm_banks remove check for bank not being available
- rework order of locals and remove else in zynqmp_r5_rproc_kick
- document and update logic for zynqmp_r5_parse_fw
- add dev_dbg output in event_notified_idr_cb if
  rproc_vq_interrupt(rproc, id) == IRQ_NONE
- add comment for handle_event_notified mbox_send_message function call
- add comment for zynqmp_r5_mb_rx_cb
- update zynqmp_r5_setup_mbox to match convention of mbox setup in ST
  remoteproc drivers
- change return in zynqmp_r5_setup_mbox to use PTR_ERR
- add zynqmp_r5_cleanup_mbox
- in zynqmp_r5_probe, reteurn zynqmp_r5_rproc instead of taking in as arg.
- in zynqmp_r5_probe use return of PTR_ERR and use zynqmp_r5_cleanup_mbox
- in zynqmp_r5_remoteproc_probe update use return value of zynqmp_r5_probe as
  either zynqmp_r5_rproc* or PTR_ERR
- update loop that cleans up cluster and mboxes in zynqmp_r5_remoteproc_probe
- update loop that cleans up cluster and mboxes in zynqmp_r5_remoteproc_remove
---
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 898 ++
 3 files changed, 907 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..9e228c9ecd43
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,898 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "sram"
+#define DDR_LIST_PROP  "memory-region"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/*
+ * Map each Xilinx on-chip SRAM  Bank address to their own respective
+ * pm_node_id.
+ */
+

[PATCH v25 3/5] firmware: xilinx: Add RPU configuration APIs

2021-01-10 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index baa3d84fdcce..0ffd62d6740c 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -389,6 +389,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -553,6 +556,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v25 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2021-01-10 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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 dc43f005191c..baa3d84fdcce 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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,
@@ -380,6 +383,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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)
 {
@@ -530,6 +539,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v25 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2021-01-10 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v25:
- grammar in device tree binding's comments
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 ++
 1 file changed, 223 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..b9412c2def7b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipsets.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  $nodename:
+pattern: "^r5fss(@.*)?"
+
+  compatible:
+enum:
+  - xlnx,zynqmp-r5-remoteproc
+
+  reg:
+items:
+  - description: Address and Size of Xilinx RPU Configuration register
+
+  "#address-cells":
+const: 2
+
+  "#size-cells":
+const: 2
+
+  ranges: true
+
+# Optional properties:
+# 
+  xlnx,cluster-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configuration Mode for the Dual R5F cores within the R5F cluster.
+  Should be either a value of 1 (LockStep mode) or 0 (Split mode),
+  default is LockStep mode if omitted.
+
+
+#R5F Processor Child Nodes:
+# ==
+
+patternProperties:
+  "^r5f_[a-f0-9]+$":
+type: object
+description: |
+  The R5F Sub-System device node should define one or two R5F child nodes,
+  each node representing a Xilinx instantiation of the Arm Cortex R5F core.
+  There should be one or two child nodes if the R5F is in Split mode and
+  one child node if the R5F is in Lockstep mode.
+
+  In Split mode each R5F core has two associated TCM Banks. R5_0 has
+  TCM Banks 0A and 0B and R5_1 has TCM Banks 1A and 1B.
+
+  In Lockstep mode only one R5F child node should be defined. This one
+  child has access to TCM Banks 0A, 0B, 1A and 1B and any of the four can
+  be included in the child R5F's sram property.
+
+  The example below shows Split mode with two child nodes.
+
+properties:
+  compatible:
+enum:
+  - xilinx,r5f
+
+# The following properties are mandatory for R5F Core0 in both LockStep and 
Split
+# modes, and are mandatory for R5F Core1 _only_ in Split mode.
+
+  memory-region:
+description: |
+  Phandles to the memory nodes to be associated with the
+  The reserved memory nodes should be carveout nodes, and
+  should be defined with a "no-map" property as per the bindings in
+  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+minItems: 1
+maxItems: 6
+items:
+  - description: Region used for dynamic DMA allocations like vrings 
and
+ vring buffers
+  - description: Region reserved for firmware image sections
+additionalItems: true
+
+  power-domain:
+description: |
+  Power node ID that is used to uniquely identify the RPU for Xilinx
+  Power Management.
+maxItems: 1
+
+# Optional properties:
+# 
+# The following properties are optional properties for each of the R5F cores:
+
+  mboxes:
+description: |
+  Standard property to specify a mailbox
+  This property is required only if the rpmsg/virtio functionality
+  is used
+
+   Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+   property
+maxItems: 1
+
+  mbox-names:
+description: |
+  Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+  property
+items:
+  - const: tx
+  - const: rx
+
+  sram:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+minItems: 1
+maxItems: 4
+description: |
+  Phandles to one or more reserved on-chip SRAM regions. The regions
+  

[PATCH v25 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2021-01-10 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in two different
configurations -
* Split
* Lockstep

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

v25:
- reword error message for rpu configuration
- change char name[15] to 16 chars to have null terminated string
  in parse_mem_regions()
- reword comments in tcm_mem_alloc
- grammar in device tree bindings
- call xilinx platform cleanup in parse_tcm_banks() case of failure
- check value of mbox_send_message in all calls within this driver
- update include/linux/firmware/xlnx-zynqmp.h style to match for enum
  pm_node_id
- indentation in zynqmp_r5_remoteproc driver
- update style of constructing carveouts to match convention in ST
  remoteproc drivers. No longer iterate through memory-region property
  using of_count_phandle_with_args. Instead use of_phandle_iterator
- use rproc_of_resm_mem_entry_init for vdev0buffer carveout as per feedback
- rework loop in zynqmp_r5_pm_request_sram as per feedback
- fix comment and linebreak in tcm_mem_alloc description
- add comments and remove extraneous devm_ioremap_wc call in tcm_mem_alloc
- in parse_tcm_banks remove check for bank not being available
- rework order of locals and remove else in zynqmp_r5_rproc_kick
- document and update logic for zynqmp_r5_parse_fw
- add dev_dbg output in event_notified_idr_cb if
  rproc_vq_interrupt(rproc, id) == IRQ_NONE
- add comment for handle_event_notified mbox_send_message function call
- add comment for zynqmp_r5_mb_rx_cb
- update zynqmp_r5_setup_mbox to match convention of mbox setup in ST
  remoteproc drivers
- change return in zynqmp_r5_setup_mbox to use PTR_ERR
- add zynqmp_r5_cleanup_mbox
- in zynqmp_r5_probe, reteurn zynqmp_r5_rproc instead of taking in as arg.
- in zynqmp_r5_probe use return of PTR_ERR and use zynqmp_r5_cleanup_mbox
- in zynqmp_r5_remoteproc_probe update use return value of zynqmp_r5_probe as
  either zynqmp_r5_rproc* or PTR_ERR
- update loop that cleans up cluster and mboxes in zynqmp_r5_remoteproc_probe
- update loop that cleans up cluster and mboxes in zynqmp_r5_remoteproc_remove

Previous version:
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=393387


Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 +
 drivers/firmware/xilinx/zynqmp.c  |  96 ++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 897 ++
 include/linux/firmware/xlnx-zynqmp.h  |  66 +-
 6 files changed, 1290 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v25 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2021-01-10 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration and TCM Nodes for
later use via request_node and release_node

Signed-off-by: Ben Levinsky 
---
v25:
- update include/linux/firmware/xlnx-zynqmp.h style to match for enum
---
 include/linux/firmware/xlnx-zynqmp.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..e4044cae0713 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
@@ -273,6 +292,10 @@ enum zynqmp_pm_request_ack {
 };
 
 enum pm_node_id {
+   NODE_TCM_0_A = 15,
+   NODE_TCM_0_B,
+   NODE_TCM_1_A,
+   NODE_TCM_1_B,
NODE_SD_0 = 39,
NODE_SD_1,
 };
-- 
2.17.1



RE: [PATCH v24 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-12-07 Thread Ben Levinsky
Hi Mathieu,

Thanks for the clarification. IIRC he is on the device tree list so should see 
this. Ill add him on this particular thread to be safe.

+Rob

Best,
Ben


> -Original Message-
> From: Mathieu Poirier 
> Sent: Monday, December 7, 2020 10:04 AM
> To: Ben Levinsky 
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v24 4/5] dt-bindings: remoteproc: Add documentation for
> ZynqMP R5 rproc bindings
> 
> Rob Herring is the maintainer of all the yaml files - he is the one this patch
> needs to go to.  I merely look at them to understand the platform device
> implementation.
> 
> On Mon, Nov 30, 2020 at 07:57:16AM -0800, Ben Levinsky wrote:
> > Add binding for ZynqMP R5 OpenAMP.
> >
> > Represent the RPU domain resources in one device node. Each RPU
> > processor is a subnode of the top RPU domain node.
> >
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ben Levinsky 
> > ---
> > v24: update for 'make dt_binding_check' errors
> > ---
> >  .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 ++
> >  1 file changed, 223 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-
> r5-remoteproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml
> > new file mode 100644
> > index ..bccbdee8c3f2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml
> > @@ -0,0 +1,223 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Xilinx R5 remote processor controller bindings
> > +
> > +description:
> > +  This document defines the binding for the remoteproc component that
> loads and
> > +  boots firmwares on the Xilinx Zynqmp and Versal family chipsets.
> > +
> > +  Note that the Linux has global addressing view of the R5-related memory
> (TCM)
> > +  so the absolute address ranges are provided in TCM reg's.
> > +
> > +maintainers:
> > +  - Ed Mooring 
> > +  - Ben Levinsky 
> > +
> > +properties:
> > +  $nodename:
> > +pattern: "^r5fss(@.*)?"
> > +
> > +  compatible:
> > +enum:
> > +  - xlnx,zynqmp-r5-remoteproc
> > +
> > +  reg:
> > +items:
> > +  - description: Address and Size of Xilinx RPU Configuration register
> > +
> > +  "#address-cells":
> > +const: 2
> > +
> > +  "#size-cells":
> > +const: 2
> > +
> > +  ranges: true
> > +
> > +# Optional properties:
> > +# 
> > +  xlnx,cluster-mode:
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +enum: [0, 1]
> > +description: |
> > +  Configuration Mode for the Dual R5F cores within the R5F cluster.
> > +  Should be either a value of 1 (LockStep mode) or 0 (Split mode),
> > +  default is LockStep mode if omitted.
> > +
> > +
> > +#R5F Processor Child Nodes:
> > +# ==
> > +
> > +patternProperties:
> > +  "^r5f_[a-f0-9]+$":
> > +type: object
> > +description: |
> > +  The R5F Sub-System device node should define one or two R5F child
> nodes,
> > +  each node representing a Xilinx instantiation of the Arm Cortex R5F
> core.
> > +  There should be one or two child nodes if the R5F is in Split mode 
> > and
> > +  one child node if the R5F is in Lockstep mode.
> > +
> > +  In Split mode each R5F core has two associated TCM Banks. R5_0 has
> > +  TCM Banks 0A and 0B and R5_1 has TCM Banks 1A and 1B.
> > +
> > +  In Lockstep mode only one R5F child node should be defined. This one
> > +  child has access to TCM Banks 0A, 0B, 1A and 1B and any of the four
> can
> > +  be included in the child R5F's sram property.
> > +
> > +  The example below shows Split mode with two child nodes.
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - xilinx,r5f

[PATCH v24 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-11-30 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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 0dd2d188f8aa..0cc862b26263 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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,
@@ -380,6 +383,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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)
 {
@@ -530,6 +539,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v24 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-11-30 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration and TCM Nodes for
later use via request_node and release_node

Signed-off-by: Ben Levinsky 
---
 include/linux/firmware/xlnx-zynqmp.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..0dd2d188f8aa 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
@@ -273,6 +292,10 @@ enum zynqmp_pm_request_ack {
 };
 
 enum pm_node_id {
+   NODE_TCM_0_A = 0xf,
+   NODE_TCM_0_B = 0x10,
+   NODE_TCM_1_A = 0x11,
+   NODE_TCM_1_B = 0x12,
NODE_SD_0 = 39,
NODE_SD_1,
 };
-- 
2.17.1



[PATCH v24 3/5] firmware: xilinx: Add RPU configuration APIs

2020-11-30 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 0cc862b26263..0104d9b8dfd9 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -389,6 +389,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -553,6 +556,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v24 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-11-30 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v24: update for 'make dt_binding_check' errors
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 ++
 1 file changed, 223 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..bccbdee8c3f2
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipsets.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  $nodename:
+pattern: "^r5fss(@.*)?"
+
+  compatible:
+enum:
+  - xlnx,zynqmp-r5-remoteproc
+
+  reg:
+items:
+  - description: Address and Size of Xilinx RPU Configuration register
+
+  "#address-cells":
+const: 2
+
+  "#size-cells":
+const: 2
+
+  ranges: true
+
+# Optional properties:
+# 
+  xlnx,cluster-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configuration Mode for the Dual R5F cores within the R5F cluster.
+  Should be either a value of 1 (LockStep mode) or 0 (Split mode),
+  default is LockStep mode if omitted.
+
+
+#R5F Processor Child Nodes:
+# ==
+
+patternProperties:
+  "^r5f_[a-f0-9]+$":
+type: object
+description: |
+  The R5F Sub-System device node should define one or two R5F child nodes,
+  each node representing a Xilinx instantiation of the Arm Cortex R5F core.
+  There should be one or two child nodes if the R5F is in Split mode and
+  one child node if the R5F is in Lockstep mode.
+
+  In Split mode each R5F core has two associated TCM Banks. R5_0 has
+  TCM Banks 0A and 0B and R5_1 has TCM Banks 1A and 1B.
+
+  In Lockstep mode only one R5F child node should be defined. This one
+  child has access to TCM Banks 0A, 0B, 1A and 1B and any of the four can
+  be included in the child R5F's sram property.
+
+  The example below shows Split mode with two child nodes.
+
+properties:
+  compatible:
+enum:
+  - xilinx,r5f
+
+# The following properties are mandatory for R5F Core0 in both LockStep and 
Split
+# modes, and are mandatory for R5F Core1 _only_ in Split mode.
+
+  memory-region:
+description: |
+  Phandles to the memory nodes to be associated with the
+  The reserved memory nodes should be carveout nodes, and
+  should be defined with a "no-map" property as per the bindings in
+  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+minItems: 1
+maxItems: 6
+items:
+  - description: Region used for dynamic DMA allocations like vrings 
and
+ vring buffers
+  - description: region reserved for firmware image sections
+additionalItems: true
+
+  power-domain:
+description: |
+  Power node ID that is used to uniquely identify the RPU for Xilinx
+  Power Management.
+maxItems: 1
+
+# Optional properties:
+# 
+# The following properties are optional properties for each of the R5F cores:
+
+  mboxes:
+description: |
+  Standard property to specify a mailbox
+  This property is required only if the rpmsg/virtio functionality
+  is used
+
+   Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+   property
+maxItems: 1
+
+  mbox-names:
+description: |
+  Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+  property
+items:
+  - const: tx
+  - const: rx
+
+  sram:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+minItems: 1
+maxItems: 4
+description: |
+  Phandles to one or more reserved on-chip SRAM regions. The regions
+  

[PATCH v24 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-30 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in two different
configurations -
* Split
* Lockstep

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 872 ++
 3 files changed, 881 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..2593de618409
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,872 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "sram"
+#define DDR_LIST_PROP  "memory-region"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/*
+ * Map each Xilinx on-chip SRAM  Bank address to their own respective
+ * pm_node_id.
+ */
+struct sram_addr_data {
+   phys_addr_t addr;
+   enum pm_node_id id;
+};
+
+#define NUM_SRAMS 4U
+static const struct sram_addr_data zynqmp_banks[NUM_SRAMS] = {
+   {0xffe0UL, NODE_TCM_0_A},
+   {0xffe2UL, NODE_TCM_0_B},
+   {0xffe9UL, NODE_TCM_1_A},
+   {0xffebUL, NODE_TCM_1_B},
+};
+
+/**
+ * struct zynqmp_r5_rproc - ZynqMP R5 core structure
+ *
+ * @rx_mc_buf: rx mailbox client buffer to save the rx message
+ * @tx_mc: tx mailbox client
+ * @rx_mc: rx mailbox client
+ * @mbox_work: mbox_work for the RPU remoteproc
+ * @tx_mc_skbs: socket buffers for tx mailbox client
+ * @dev: device of RPU instance
+ * @rproc: rproc handle
+ * @tx_chan: tx mailbox channel
+ * @rx_chan: rx mailbox channel
+ * @pnode_id: RPU CPU power domain id
+ * @elem: linked list item
+ */
+struct zynqmp_r5_rproc {
+   unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
+   struct mbox_client tx_mc;
+   struct mbox_client rx_mc;
+   struct work_struct mbox_work;
+   struct sk_buff_head tx_mc_skbs;
+   struct device *dev;
+   struct rproc *rproc;
+   struct mbox_chan *tx_chan;
+   struct mbox_chan *rx_chan;
+   u32 pnode_id;
+   struct list_head elem;
+};
+
+/*
+ * r5_set_mode - set RPU operation mode
+ * @z_rproc: Remote processor private data
+ * @rpu_mode: mode specified by device tree to configure the RPU to
+ *
+ * set RPU operation mode
+ *
+ * Return: 0 for success, negative value for failure
+ */
+static int r5_set_mode(struct zynqmp_r5_rproc *z_rproc,
+  enum rpu_oper_mode rpu_mode)
+{
+   enum rpu_tcm_comb tcm_mode;
+   enum rpu_oper_mode cur_rpu_mode;
+   int ret;
+
+   ret = zynqmp_pm_get_rpu_mode(z_rproc->pnode_id, _rpu_mode);
+   if (ret < 0)
+   return ret;
+
+

[PATCH v24 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-11-30 Thread Ben Levinsky


v24:
fix  'make dt_binding_check' errors

v23:
- add TCM Nodes to xlnx-zynqmp.h to be used in R5 Remoteproc Driver
- Update grammar and capitalization in device tree bindings and R5 remoteproc
  driver comments
- Update device tree bindings and driver to align with TI Remoteproc R5 driver
- fix minor comments in v22 review

Previous version:
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=384227

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 223 +
 drivers/firmware/xilinx/zynqmp.c  |  96 ++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 872 ++
 include/linux/firmware/xlnx-zynqmp.h  |  64 ++
 6 files changed, 1264 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



RE: [PATCH v23 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-30 Thread Ben Levinsky
Hi Mathieu,

Thanks for the tip. I will fix up the DT Schema bot output this week then

Best
Ben

> -Original Message-
> From: Mathieu Poirier 
> Sent: Monday, November 30, 2020 7:32 AM
> To: Ben Levinsky 
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v23 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> On Sun, Nov 29, 2020 at 05:20:23PM +, Ben Levinsky wrote:
> > Ping for comments
> >
> 
> I plan on reviewing Grzegorz's PRU set before this one and as such won't get
> to
> yours well into next week or the one after.  I noticed Rob found errors in
> the DT schema - those need fixing anyway.
> 
> >
> > > -Original Message-
> > > From: Ben Levinsky 
> > > Sent: Saturday, November 14, 2020 8:49 AM
> > > To: mathieu.poir...@linaro.org
> > > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > > Subject: [PATCH v23 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> > > driver
> > >
> > > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > > remotproc driver, we can boot the R5 sub-system in two different
> > > configurations -
> > >   * Split
> > >   * Lockstep
> > >
> > > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > > Platform Management Unit that handles the R5 configuration, memory
> access
> > > and R5 lifecycle management. The interface to this manager is done in this
> > > driver via zynqmp_pm_* function calls.
> > >
> > > Signed-off-by: Wendy Liang 
> > > Signed-off-by: Michal Simek 
> > > Signed-off-by: Ed Mooring 
> > > Signed-off-by: Jason Wu 
> > > Signed-off-by: Ben Levinsky 
> > > ---
> > > - Rework R5 cluster configuration so alignment of
> > >   of_property_read_bool(dev->of_node, "lockstep-mode") is non-issue
> > >   (Note that property 'lockstep-mode' is now 'xilinx,cluster-mode'
> > >   to align with TI R5 driver).
> > > - Update grammatic and capitalization errors in driver and documentation
> > > - Refactor var in zynqmp_r5_remoteproc_probe 'i' -> 'core_count'
> > >   Remove the use of this near loop for instantiating each core.
> > > - Refactor to more closely align with TI remoteproc R5 driver as follows:
> > >   > Refactor 'meta-memory-regions' property -> 'sram'
> > >   > Change Xilinx specific TCM nodes to generic mmio-sram nodes. Remove
> the
> > > power node ID from each of these TCM nodes and instead map the TCM
> > > addresses to respective Xilinx Platorm Node IDs via lookup table
> > > zynqmp_banks
> > >   > Refactor 'pnode-id' -> 'power-domain' for R5 Xilix Platform Node ID.
> > > ---
> > >  drivers/remoteproc/Kconfig|   8 +
> > >  drivers/remoteproc/Makefile   |   1 +
> > >  drivers/remoteproc/zynqmp_r5_remoteproc.c | 872
> > > ++
> > >  3 files changed, 881 insertions(+)
> > >  create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c
> > >
> > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > > index c6659dfea7c7..c2fe54b1d94f 100644
> > > --- a/drivers/remoteproc/Kconfig
> > > +++ b/drivers/remoteproc/Kconfig
> > > @@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
> > > It's safe to say N here if you're not interested in utilizing
> > > the DSP slave processors.
> > >
> > > +config ZYNQMP_R5_REMOTEPROC
> > > + tristate "ZynqMP R5 remoteproc support"
> > > + depends on PM && ARCH_ZYNQMP
> > > + select RPMSG_VIRTIO
> > > + select ZYNQMP_IPI_MBOX
> > > + help
> > > +   Say y or m here to support ZynqMP R5 remote processors via the
> > > remote
> > > +   processor framework.
> > >  endif # REMOTEPROC
> > >
> > >  endmenu
> > > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > > index 3dfa28e6c701..ef1abff654c2 100644
> > > --- a/drivers/remoteproc/Makefile
> > > +++ b/drivers/remoteproc/Makefile
> > > @@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC) +=
> > > st_remoteproc.o
> > >  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> > >  obj-$(CONFIG_STM32_RPROC)+

RE: [PATCH v23 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-29 Thread Ben Levinsky
Ping for comments


> -Original Message-
> From: Ben Levinsky 
> Sent: Saturday, November 14, 2020 8:49 AM
> To: mathieu.poir...@linaro.org
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v23 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in two different
> configurations -
>   * Split
>   * Lockstep
> 
> The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> Platform Management Unit that handles the R5 configuration, memory access
> and R5 lifecycle management. The interface to this manager is done in this
> driver via zynqmp_pm_* function calls.
> 
> Signed-off-by: Wendy Liang 
> Signed-off-by: Michal Simek 
> Signed-off-by: Ed Mooring 
> Signed-off-by: Jason Wu 
> Signed-off-by: Ben Levinsky 
> ---
> - Rework R5 cluster configuration so alignment of
>   of_property_read_bool(dev->of_node, "lockstep-mode") is non-issue
>   (Note that property 'lockstep-mode' is now 'xilinx,cluster-mode'
>   to align with TI R5 driver).
> - Update grammatic and capitalization errors in driver and documentation
> - Refactor var in zynqmp_r5_remoteproc_probe 'i' -> 'core_count'
>   Remove the use of this near loop for instantiating each core.
> - Refactor to more closely align with TI remoteproc R5 driver as follows:
>   > Refactor 'meta-memory-regions' property -> 'sram'
>   > Change Xilinx specific TCM nodes to generic mmio-sram nodes. Remove the
> power node ID from each of these TCM nodes and instead map the TCM
> addresses to respective Xilinx Platorm Node IDs via lookup table
> zynqmp_banks
>   > Refactor 'pnode-id' -> 'power-domain' for R5 Xilix Platform Node ID.
> ---
>  drivers/remoteproc/Kconfig|   8 +
>  drivers/remoteproc/Makefile   |   1 +
>  drivers/remoteproc/zynqmp_r5_remoteproc.c | 872
> ++
>  3 files changed, 881 insertions(+)
>  create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index c6659dfea7c7..c2fe54b1d94f 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
> It's safe to say N here if you're not interested in utilizing
> the DSP slave processors.
> 
> +config ZYNQMP_R5_REMOTEPROC
> + tristate "ZynqMP R5 remoteproc support"
> + depends on PM && ARCH_ZYNQMP
> + select RPMSG_VIRTIO
> + select ZYNQMP_IPI_MBOX
> + help
> +   Say y or m here to support ZynqMP R5 remote processors via the
> remote
> +   processor framework.
>  endif # REMOTEPROC
> 
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 3dfa28e6c701..ef1abff654c2 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC) +=
> st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
>  obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
>  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)   += ti_k3_dsp_remoteproc.o
> +obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC)   += zynqmp_r5_remoteproc.o
> diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c
> b/drivers/remoteproc/zynqmp_r5_remoteproc.c
> new file mode 100644
> index ..6bffbc2d7e91
> --- /dev/null
> +++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
> @@ -0,0 +1,872 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Zynq R5 Remote Processor driver
> + *
> + * Based on origin OMAP and Zynq Remote Processor driver
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "remoteproc_internal.h"
> +
> +#define MAX_RPROCS   2 /* Support up to 2 RPU */
> +#define MAX_MEM_PNODES   4 /* Max power nodes for one RPU memory
> instance */
> +
> +#define BANK_LIST_PROP   "sram"
> +#define DDR_LIST_PROP"memory-region"
> +
> +/* IPI buffer MAX length */
> +#define IPI_BUF_LEN_MAX  32U
> +/* RX mailbox client buffer max length */
> +#define RX_MBOX_CLIENT_BUF_MAX   (IPI_BUF_LEN_MAX + \
> +  sizeof(struct zynqmp_ipi_message))
> +
> +/*
> + * Map each Xilinx on-chip SRAM  Bank address 

[PATCH v23 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-11-14 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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 0dd2d188f8aa..0cc862b26263 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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,
@@ -380,6 +383,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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)
 {
@@ -530,6 +539,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v23 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-14 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in two different
configurations -
* Split
* Lockstep

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
- Rework R5 cluster configuration so alignment of
  of_property_read_bool(dev->of_node, "lockstep-mode") is non-issue
  (Note that property 'lockstep-mode' is now 'xilinx,cluster-mode'
  to align with TI R5 driver).
- Update grammatic and capitalization errors in driver and documentation
- Refactor var in zynqmp_r5_remoteproc_probe 'i' -> 'core_count'
  Remove the use of this near loop for instantiating each core.
- Refactor to more closely align with TI remoteproc R5 driver as follows:
  > Refactor 'meta-memory-regions' property -> 'sram'
  > Change Xilinx specific TCM nodes to generic mmio-sram nodes. Remove the
power node ID from each of these TCM nodes and instead map the TCM
addresses to respective Xilinx Platorm Node IDs via lookup table
zynqmp_banks
  > Refactor 'pnode-id' -> 'power-domain' for R5 Xilix Platform Node ID.
---
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 872 ++
 3 files changed, 881 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..6bffbc2d7e91
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,872 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "sram"
+#define DDR_LIST_PROP  "memory-region"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/*
+ * Map each Xilinx on-chip SRAM  Bank address to their own respective
+ * pm_node_id.
+ */
+struct sram_addr_data {
+   phys_addr_t addr;
+   enum pm_node_id id;
+};
+
+#define NUM_SRAMS 4U
+static const struct sram_addr_data zynqmp_banks[NUM_SRAMS] = {
+   {0xffe0UL, NODE_TCM_0_A},
+   {0xffe2UL, NODE_TCM_0_B},
+   {0xffe9UL, NODE_TCM_1_A},
+   {0xffebUL, NODE_TCM_1_B},
+};
+
+/**
+ * struct zynqmp_r5_rproc - ZynqMP R5 core structure
+ *
+ * @rx_mc_buf: rx mailbox client buffer to save the rx message
+ * @tx_mc: tx mailbox client
+ * @rx_mc: rx mailbox client
+ * @mbox_work: mbox_work for the RPU remoteproc
+ * @tx_mc_skbs: socket buffers for tx mailbox client
+ * @dev: device of RPU instance
+ * @rproc: rproc handle
+ * @tx_chan: tx mailbox channel
+ * @rx_chan: rx mailbox channel
+ * @pnode_id: RPU CPU power domain id
+ * @elem: linked list item
+ */
+struct zynqmp_r5_rproc {
+   unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
+   struct mbox_clien

[PATCH v23 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-11-14 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
- Update grammar and capitalization
- Align with TI R5 Remoteproc driver as follows:
  > Change TCM node to be generic mmio sram node
  > Reword properties to align with TI R5 driver
  > Change structure of Yaml parsing to mirror TI R5 driver
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 238 ++
 1 file changed, 238 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..85c91005dbbe
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,238 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipsets.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  $nodename:
+pattern: "^r5fss(@.*)?"
+
+  compatible:
+enum:
+  - xlnx,zynqmp-r5-remoteproc
+
+  reg:
+items:
+  - description: Address and Size of Xilinx RPU Configuration register
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 1
+
+  ranges:
+const: 0
+
+# Optional properties:
+# 
+  xilinx,cluster-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configuration Mode for the Dual R5F cores within the R5F cluster.
+  Should be either a value of 1 (LockStep mode) or 0 (Split mode),
+  default is LockStep mode if omitted.
+
+
+#R5F Processor Child Nodes:
+# ==
+
+patternProperties:
+  "^r5f_[a-f0-9]+$":
+type: object
+description: |
+  The R5F Sub-System device node should define one or two R5F child nodes,
+  each node representing a Xilinx instantiation of the Arm Cortex R5F core.
+  There should be one or two child nodes if the R5F is in Split mode and
+  one child node if the R5F is in Lockstep mode.
+
+  In Split mode each R5F core has two associated TCM Banks. R5_0 has
+  TCM Banks 0A and 0B and R5_1 has TCM Banks 1A and 1B.
+
+  In Lockstep mode only one R5F child node should be defined. This one
+  child has access to TCM Banks 0A, 0B, 1A and 1B and any of the four can
+  be included in the child R5F's sram property.
+
+  The example below shows Split mode with two child nodes.
+
+properties:
+  compatible:
+enum:
+  - xilinx,r5f
+
+# The following properties are mandatory for R5F Core0 in both LockStep and 
Split
+# modes, and are mandatory for R5F Core1 _only_ in Split mode.
+
+  memory-region:
+description: |
+  Phandles to the memory nodes to be associated with the
+  The reserved memory nodes should be carveout nodes, and
+  should be defined with a "no-map" property as per the bindings in
+  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+minItems: 1
+maxItems: 6
+items:
+  - description: Region used for dynamic DMA allocations like vrings 
and
+ vring buffers
+  - description: region reserved for firmware image sections
+additionalItems: true
+
+  power-domain:
+description: |
+  Power node ID that is used to uniquely identify the RPU for Xilinx
+  Power Management.
+maxItems: 1
+
+  "#address-cells":
+const: 1
+  "#size-cells":
+const: 1
+
+# Optional properties:
+# 
+# The following properties are optional properties for each of the R5F cores:
+
+  mboxes:
+description: |
+  Standard property to specify a mailbox
+  This property is required only if the rpmsg/virtio functionality
+  is used
+
+   Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+   property
+maxItems: 2
+
+  mbox-names:
+description: |
+  Refer to the zynqmp-ipi-mailbox documentation for client usage of 
this
+ 

[PATCH v23 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-11-14 Thread Ben Levinsky
v23:
- add TCM Nodes to xlnx-zynqmp.h to be used in R5 Remoteproc Driver
- Update grammar and capitalization in device tree bindings and R5 remoteproc 
driver comments
- Update device tree bindings and driver to align with TI Remoteproc R5 driver
- fix minor comments in v22 review

Previous version:
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=376801


Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 238 +
 drivers/firmware/xilinx/zynqmp.c  |  96 ++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 872 ++
 include/linux/firmware/xlnx-zynqmp.h  |  64 ++
 6 files changed, 1279 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v23 3/5] firmware: xilinx: Add RPU configuration APIs

2020-11-14 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 0cc862b26263..0104d9b8dfd9 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -389,6 +389,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -553,6 +556,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v23 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-11-14 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration and TCM Nodes for
later use via request_node and release_node

Signed-off-by: Ben Levinsky 
---
v23: add TCM Node IDs to be used in R5 Remoteproc driver
---
 include/linux/firmware/xlnx-zynqmp.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..0dd2d188f8aa 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
@@ -273,6 +292,10 @@ enum zynqmp_pm_request_ack {
 };
 
 enum pm_node_id {
+   NODE_TCM_0_A = 0xf,
+   NODE_TCM_0_B = 0x10,
+   NODE_TCM_1_A = 0x11,
+   NODE_TCM_1_B = 0x12,
NODE_SD_0 = 39,
NODE_SD_1,
 };
-- 
2.17.1



RE: [PATCH v22 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-04 Thread Ben Levinsky
Hi Mathieu,

> -Original Message-
> From: Mathieu Poirier 
> Sent: Wednesday, November 4, 2020 1:30 PM
> To: Ben Levinsky 
> Cc: michael.auch...@ni.com; Stefano Stabellini ;
> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v22 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> On Tue, Nov 03, 2020 at 10:23:39AM -0800, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in different 2
> > configurations -
> > * split
> > * lock-step
> >
> > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > Platform Management Unit that handles the R5 configuration, memory
> access
> > and R5 lifecycle management. The interface to this manager is done in this
> > driver via zynqmp_pm_* function calls.
> >
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ed Mooring 
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Ben Levinsky 
> > ---
> > - update documented param list for zynqmp_r5_probe
> > - remove use-after-free lines in zynqmp_r5_probe,
> >   zynqmp_r5_remoteproc_probe, and zynqmp_r5_remoteproc_remove
> > - update path for error handling in zynqmp_r5_probe and
> >   zynqmp_r5_remoteproc_probe
> > - as the mbox properties are optional, update zynqmp_r5_rproc_kick
> >   so that the mailbox functionality only occurs if these
> >   properties are provided
> > ---
> >  drivers/remoteproc/Kconfig|   8 +
> >  drivers/remoteproc/Makefile   |   1 +
> >  drivers/remoteproc/zynqmp_r5_remoteproc.c | 778
> ++
> 
> Many of my comments from V19 have not been addressed and as such I will
> not move
> foward with this set.  Moreover I will not consider a new revision before
> November 18th.
> 

Thank you for the advance notice. 

As for V19 comments that are unresolved, can you expand on which ones?
>From the v19 review here is a list of the comments with your comments 
>surrounded by quotes
and how I had thought these were addressed. 

"
As far as I can see zynqmp_r5_rproc::dt_node is not needed
" 

I removed the field zynqmp_r5_rproc::dt_node and its no longer used in 
the file

"
> + z_rproc->dev = _ptr->dev;
> + z_rproc->dev->of_node = node;

This is quite hackish to me.  The problem is that @pdev is the rpu'a DT node
rather than the r5_X's DT node.  I suggest to have a look at k3_r5_probe()[1],
especially at how devm_of_platform_populate() is called on @dev and from there
how the platform device for each r5 is retreived using the same
for_each_available_child_of_node() loop you also have.
"
As I understand it this is resolved as now @pdev is the r5_X's DT node 
similar to the k3_r5_probe()
Also the 2 lines in question are now removed in the v22 patch


"> +struct zynqmp_r5_rproc *core;

Please call variables of type zynqmp_r5_rproc the same name throughout the file.
"
So in zynqmp_r5_probe there is an instance of a zynqmp_r5_rproc** with 
the name core, this is because
there is already arg with name z_rproc and z_rproc_ptr or something 
like this may be confusing.

With that being said, instead the zynqmp_r5_rproc** can be renamed to 
z_rproc if this is what you 
mean?

"
> + rpu_mode = of_property_read_bool(dev->of_node, "lockstep-mode") ?
> + PM_RPU_MODE_LOCKSTEP : PM_RPU_MODE_SPLIT;

Indentation problem.  Note that is it now permitted to go beyond 80 characters
per line.
"

In v22 patch this is now:
rpu_mode = of_property_read_bool(dev->of_node, "lockstep-mode") 
?
PM_RPU_MODE_LOCKSTEP : PM_RPU_MODE_SPLIT;

Is this indentation alright?

"
> + i = 0;

What is the above for?  As fas as I can tell 'i' is not used in the loop below.
"
In v19 this var was deprecated, but as per feedback from Michael A. in 
later revisions there was unhandled 
case of R5_0 successfully initializating but R5_1 failing. To 
accommodate this case the var i was
re-introduced. If the name is unclear then it can be refactored if this 
is the intention

"
> + struct list_head *pos, *cluster = (struct list_head *)
> +  platform_get_drvdata(pdev);

Either align the 'p' with the '(' or simply do the assignement on another line
below.
"

This may be formatting on my terminal vs. the patch format itself but 
in v22 I think this is resolved.



If still 1 or mor

[PATCH v22 3/5] firmware: xilinx: Add RPU configuration APIs

2020-11-03 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v22 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-11-03 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 143 ++
 1 file changed, 143 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..9cb358389cd7
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: xlnx,zynqmp-r5-remoteproc
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+type: boolean
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-regions:
+description:
+  Collection of memory carveouts used for elf-loading and inter-processor
+  communication. each carveout in this case should be in DDR, not
+  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  meta-memory-regions:
+description:
+  Collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack.
+  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
+  BRAM, OCM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  pnode-id:
+maxItems: 1
+description:
+  Power node id that is used to uniquely identify the node for Xilinx
+  Power Management. The value is then passed to Xilinx platform
+  manager for power on/off and access.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  mboxes:
+description:
+  Array of phandles that describe the rx and tx for xilinx zynqmp
+  mailbox driver. order of rx and tx is described by the mbox-names
+  property. This will be used for communication with remote
+  processor.
+maxItems: 2
+
+  mbox-names:
+description:
+  Array of strings that denote which item in the mboxes property array
+  are the rx and tx for xilinx zynqmp mailbox driver
+maxItems: 2
+$ref: /schemas/types.yaml#/definitions/string-array
+
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+
+  rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+   no-map;
+   reg = <0x3ed4 0x4000>;
+  };
+  rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+   no-map;
+   reg = <0x3ed44000 0x4000>;
+  };
+  rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+   no-map;
+   reg = <0x3ed48000 0x10>;
+  };
+
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes or label as disabled in
+  * status property
+  */
+ tcm0a: tcm_0a@ffe0 {
+ reg = <0xffe0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ phandle = <0x40>;
+ };
+ tcm0b: tcm_1a@ffe2 {
+ reg = <0xffe2 0x1>;
+ pnode-id = <0x10>;
+ no-map;
+ status = "okay";
+ phandle = <0x41>;
+ };
+
+ rpu {
+  compatible = "xlnx,zynqmp-r5-remoteproc";
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  lockstep-mode;
+  r5_0 {
+   compatib

[PATCH v22 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-11-03 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v22 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-11-03 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v22 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-03 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
- update documented param list for zynqmp_r5_probe
- remove use-after-free lines in zynqmp_r5_probe,
  zynqmp_r5_remoteproc_probe, and zynqmp_r5_remoteproc_remove
- update path for error handling in zynqmp_r5_probe and
  zynqmp_r5_remoteproc_probe
- as the mbox properties are optional, update zynqmp_r5_rproc_kick
  so that the mailbox functionality only occurs if these
  properties are provided
---
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 778 ++
 3 files changed, 787 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..48bffa91bc00
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,779 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "meta-memory-regions"
+#define DDR_LIST_PROP  "memory-regions"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/**
+ * struct zynqmp_r5_mem - zynqmp rpu memory data
+ * @pnode_id: TCM power domain ids
+ * @res: memory resource
+ * @node: list node
+ */
+struct zynqmp_r5_mem {
+   u32 pnode_id[MAX_MEM_PNODES];
+   struct resource res;
+   struct list_head node;
+};
+
+/**
+ * struct zynqmp_r5_rproc - zynqmp rpu remote processor state
+ * this is for each individual R5 core's state
+ *
+ * @rx_mc_buf: rx mailbox client buffer to save the rx message
+ * @tx_mc: tx mailbox client
+ * @rx_mc: rx mailbox client * @dev: device of RPU instance
+ * @mbox_work: mbox_work for the RPU remoteproc
+ * @tx_mc_skbs: socket buffers for tx mailbox client
+ * @dev: device of RPU instance
+ * @rproc: rproc handle
+ * @tx_chan: tx mailbox channel
+ * @rx_chan: rx mailbox channel
+ * @pnode_id: RPU CPU power domain id
+ * @elem: linked list item
+ * @dt_node: device tree node that holds information for 1 R5 core.
+ */
+struct zynqmp_r5_rproc {
+   unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
+   struct mbox_client tx_mc;
+   struct mbox_client rx_mc;
+   struct work_struct mbox_work;
+   struct sk_buff_head tx_mc_skbs;
+   struct device *dev;
+   struct rproc *rproc;
+   struct mbox_chan *tx_chan;
+   struct mbox_chan *rx_chan;
+   u32 pnode_id;
+   struct list_head elem;
+};
+
+/*
+ * r5_set_mode - set RPU operation mode
+ * @z_rproc: Remote processor private data
+ * @rpu_mode: mode specified by device tree to con

[PATCH v22 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-11-03 Thread Ben Levinsky
Update Xilinx R5 Remoteproc Driver as follows:
- update documented param list for zynqmp_r5_probe
- remove use-after-free lines in zynqmp_r5_probe,
  zynqmp_r5_remoteproc_probe, and zynqmp_r5_remoteproc_remove
- update path for error handling in zynqmp_r5_probe and
  zynqmp_r5_remoteproc_probe
- update zynqmp_r5_rproc_kick to only use mailbox-related
  properties if the rproc pointer's corresponding of_node
  has mbox properties present, otherwise kick should and will
  do nothing

Previous version 
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=374399

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 143 
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 779 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1087 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



RE: [PATCH v21 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-02 Thread Ben Levinsky
Hi Michael,

> -Original Message-
> From: Michael Auchter 
> Sent: Monday, November 2, 2020 1:14 PM
> To: Ben Levinsky 
> Cc: Stefano Stabellini ; mathieu.poir...@linaro.org;
> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v21 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> On Mon, Nov 02, 2020 at 11:38:59AM -0800, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in different 2
> > configurations -
> > * split
> > * lock-step
> >
> > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > Platform Management Unit that handles the R5 configuration, memory
> access
> > and R5 lifecycle management. The interface to this manager is done in this
> > driver via zynqmp_pm_* function calls.
> >
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ed Mooring 
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Ben Levinsky 
> > ---
> > Update Xilinx R5 Remoteproc Driver as follows:
> > - update documentation for zynqmp_r5_probe
> > - restructure so that cluster initialization code is all in one place
> > - add memory allocation check for cluster
> > - add error handling in case of second core fails at probe but first core
> succeeded.
> >   to clean up the first core
> > - remove unneeded lines in zynqmp_r5_remoteproc_remove
> > ---
> >
> >  drivers/remoteproc/Kconfig|   8 +
> >  drivers/remoteproc/Makefile   |   1 +
> >  drivers/remoteproc/zynqmp_r5_remoteproc.c | 784
> ++
> >  3 files changed, 793 insertions(+)
> >  create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index c6659dfea7c7..c2fe54b1d94f 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
> >   It's safe to say N here if you're not interested in utilizing
> >   the DSP slave processors.
> >
> > +config ZYNQMP_R5_REMOTEPROC
> > +   tristate "ZynqMP R5 remoteproc support"
> > +   depends on PM && ARCH_ZYNQMP
> > +   select RPMSG_VIRTIO
> > +   select ZYNQMP_IPI_MBOX
> > +   help
> > + Say y or m here to support ZynqMP R5 remote processors via the
> remote
> > + processor framework.
> >  endif # REMOTEPROC
> >
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 3dfa28e6c701..ef1abff654c2 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   +=
> st_remoteproc.o
> >  obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
> >  obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
> >  obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> > +obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
> > diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c
> b/drivers/remoteproc/zynqmp_r5_remoteproc.c
> > new file mode 100644
> > index ..993bd72e5664
> > --- /dev/null
> > +++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
> > @@ -0,0 +1,784 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Zynq R5 Remote Processor driver
> > + *
> > + * Based on origin OMAP and Zynq Remote Processor driver
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "remoteproc_internal.h"
> > +
> > +#define MAX_RPROCS 2 /* Support up to 2 RPU */
> > +#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory
> instance */
> > +
> > +#define BANK_LIST_PROP "meta-memory-regions"
> > +#define DDR_LIST_PROP  "memory-regions"
> > +
> > +/* IPI buffer MAX length */
> > +#define IPI_BUF_LEN_MAX32U
> > +/* RX mailbox client buffer max length */
> > +#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
> > +sizeof(struct zynqmp_ipi_message))
> > +
> > +/**
> 

[PATCH v21 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-11-02 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v21 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-11-02 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v21 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-11-02 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
Update Xilinx R5 Remoteproc Driver as follows:
- update documentation for zynqmp_r5_probe
- restructure so that cluster initialization code is all in one place
- add memory allocation check for cluster
- add error handling in case of second core fails at probe but first core 
succeeded.
  to clean up the first core
- remove unneeded lines in zynqmp_r5_remoteproc_remove
---

 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 784 ++
 3 files changed, 793 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..993bd72e5664
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,784 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "meta-memory-regions"
+#define DDR_LIST_PROP  "memory-regions"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/**
+ * struct zynqmp_r5_mem - zynqmp rpu memory data
+ * @pnode_id: TCM power domain ids
+ * @res: memory resource
+ * @node: list node
+ */
+struct zynqmp_r5_mem {
+   u32 pnode_id[MAX_MEM_PNODES];
+   struct resource res;
+   struct list_head node;
+};
+
+/**
+ * struct zynqmp_r5_rproc - zynqmp rpu remote processor state
+ * this is for each individual R5 core's state
+ *
+ * @rx_mc_buf: rx mailbox client buffer to save the rx message
+ * @tx_mc: tx mailbox client
+ * @rx_mc: rx mailbox client * @dev: device of RPU instance
+ * @mbox_work: mbox_work for the RPU remoteproc
+ * @tx_mc_skbs: socket buffers for tx mailbox client
+ * @dev: device of RPU instance
+ * @rproc: rproc handle
+ * @tx_chan: tx mailbox channel
+ * @rx_chan: rx mailbox channel
+ * @pnode_id: RPU CPU power domain id
+ * @elem: linked list item
+ * @dt_node: device tree node that holds information for 1 R5 core.
+ */
+struct zynqmp_r5_rproc {
+   unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
+   struct mbox_client tx_mc;
+   struct mbox_client rx_mc;
+   struct work_struct mbox_work;
+   struct sk_buff_head tx_mc_skbs;
+   struct device *dev;
+   struct rproc *rproc;
+   struct mbox_chan *tx_chan;
+   struct mbox_chan *rx_chan;
+   u32 pnode_id;
+   struct list_head elem;
+};
+
+/*
+ * r5_set_mode - set RPU operation mode
+ * @z_rproc: Remote processor private data
+ * @rpu_mode: mode specified by device tree to configure the RPU to
+ *
+ * set 

[PATCH v21 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-11-02 Thread Ben Levinsky
Update Xilinx R5 Remoteproc Driver as follows:
- update documentation for zynqmp_r5_probe
- restructure so that cluster initialization code is all in one place
- add memory allocation check for cluster
- add error handling in case of second core fails at probe but first core 
succeeded.
- remove unneeded lines in zynqmp_r5_remoteproc_remove

Previous version 
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=374399

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 143 
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 785 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1093 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v21 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-11-02 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 143 ++
 1 file changed, 143 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..9cb358389cd7
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: xlnx,zynqmp-r5-remoteproc
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+type: boolean
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-regions:
+description:
+  Collection of memory carveouts used for elf-loading and inter-processor
+  communication. each carveout in this case should be in DDR, not
+  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  meta-memory-regions:
+description:
+  Collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack.
+  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
+  BRAM, OCM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  pnode-id:
+maxItems: 1
+description:
+  Power node id that is used to uniquely identify the node for Xilinx
+  Power Management. The value is then passed to Xilinx platform
+  manager for power on/off and access.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  mboxes:
+description:
+  Array of phandles that describe the rx and tx for xilinx zynqmp
+  mailbox driver. order of rx and tx is described by the mbox-names
+  property. This will be used for communication with remote
+  processor.
+maxItems: 2
+
+  mbox-names:
+description:
+  Array of strings that denote which item in the mboxes property array
+  are the rx and tx for xilinx zynqmp mailbox driver
+maxItems: 2
+$ref: /schemas/types.yaml#/definitions/string-array
+
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+
+  rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+   no-map;
+   reg = <0x3ed4 0x4000>;
+  };
+  rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+   no-map;
+   reg = <0x3ed44000 0x4000>;
+  };
+  rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+   no-map;
+   reg = <0x3ed48000 0x10>;
+  };
+
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes or label as disabled in
+  * status property
+  */
+ tcm0a: tcm_0a@ffe0 {
+ reg = <0xffe0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ phandle = <0x40>;
+ };
+ tcm0b: tcm_1a@ffe2 {
+ reg = <0xffe2 0x1>;
+ pnode-id = <0x10>;
+ no-map;
+ status = "okay";
+ phandle = <0x41>;
+ };
+
+ rpu {
+  compatible = "xlnx,zynqmp-r5-remoteproc";
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  lockstep-mode;
+  r5_0 {
+   compatib

[PATCH v21 3/5] firmware: xilinx: Add RPU configuration APIs

2020-11-02 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v20 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-30 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
- remove zynqmp_r5_rproc::dt_node and replace usage with
  zynqmp_r5_rproc->dev->of_node throughout file
- emulate TI K3 R5 probe use of devm_of_platform_populate to set devices for
  each R5 core's corresponding remoteproc device
- replace zynqmp_r5_rproc var name 'core' to 'z_rproc' throughout file for
  consistency
- update indentation
- remove unused var in zynqmp_r5_remoteproc_probe
- update typo in Kconfig
---
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 771 ++
 3 files changed, 780 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..c2fe54b1d94f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -275,6 +275,14 @@ config TI_K3_DSP_REMOTEPROC
  It's safe to say N here if you're not interested in utilizing
  the DSP slave processors.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP R5 remoteproc support"
+   depends on PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..ef1abff654c2 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_ST_REMOTEPROC)   += st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)   += st_slim_rproc.o
 obj-$(CONFIG_STM32_RPROC)  += stm32_rproc.o
 obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_ZYNQMP_R5_REMOTEPROC) += zynqmp_r5_remoteproc.o
diff --git a/drivers/remoteproc/zynqmp_r5_remoteproc.c 
b/drivers/remoteproc/zynqmp_r5_remoteproc.c
new file mode 100644
index ..9c917305bdae
--- /dev/null
+++ b/drivers/remoteproc/zynqmp_r5_remoteproc.c
@@ -0,0 +1,771 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq R5 Remote Processor driver
+ *
+ * Based on origin OMAP and Zynq Remote Processor driver
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define MAX_RPROCS 2 /* Support up to 2 RPU */
+#define MAX_MEM_PNODES 4 /* Max power nodes for one RPU memory instance */
+
+#define BANK_LIST_PROP "meta-memory-regions"
+#define DDR_LIST_PROP  "memory-regions"
+
+/* IPI buffer MAX length */
+#define IPI_BUF_LEN_MAX32U
+/* RX mailbox client buffer max length */
+#define RX_MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \
+sizeof(struct zynqmp_ipi_message))
+
+/**
+ * struct zynqmp_r5_mem - zynqmp rpu memory data
+ * @pnode_id: TCM power domain ids
+ * @res: memory resource
+ * @node: list node
+ */
+struct zynqmp_r5_mem {
+   u32 pnode_id[MAX_MEM_PNODES];
+   struct resource res;
+   struct list_head node;
+};
+
+/**
+ * struct zynqmp_r5_rproc - zynqmp rpu remote processor state
+ * this is for each individual R5 core's state
+ *
+ * @rx_mc_buf: rx mailbox client buffer to save the rx message
+ * @tx_mc: tx mailbox client
+ * @rx_mc: rx mailbox client * @dev: device of RPU instance
+ * @mbox_work: mbox_work for the RPU remoteproc
+ * @tx_mc_skbs: socket buffers for tx mailbox client
+ * @dev: device of RPU instance
+ * @rproc: rproc handle
+ * @tx_chan: tx mailbox channel
+ * @rx_chan: rx mailbox channel
+ * @pnode_id: RPU CPU power domain id
+ * @elem: linked list item
+ * @dt_node: device tree node that holds information for 1 R5 core.
+ */
+struct zynqmp_r5_rproc {
+   unsigned char rx_mc_buf[RX_MBOX_CLIENT_BUF_MAX];
+   struct mbox_client tx_mc;
+   struct mbox_client rx_mc;
+   struct work_struct mbox_work;
+   struct sk_buff_head tx_mc_skbs;
+   struct device *dev;
+   struct rproc *rproc;
+   struct mbox_chan *tx_chan;
+   struct mbox_chan *rx_chan;
+   u32 pnode_id;
+   struct list_head elem;
+};
+
+/*
+ * r5_set_mode - set RPU operation mode
+ * @z_rproc: Remote processor private data
+ * @rpu_mode: mode specified 

[PATCH v20 3/5] firmware: xilinx: Add RPU configuration APIs

2020-10-30 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v20 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-10-30 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v20 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-10-30 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v20:
- update typos and style
- add compat string for singular r5 core to accomodate
  devm_of_platform_populate
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 143 ++
 1 file changed, 143 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..9cb358389cd7
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: xlnx,zynqmp-r5-remoteproc
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+type: boolean
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-regions:
+description:
+  Collection of memory carveouts used for elf-loading and inter-processor
+  communication. each carveout in this case should be in DDR, not
+  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  meta-memory-regions:
+description:
+  Collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack.
+  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
+  BRAM, OCM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  pnode-id:
+maxItems: 1
+description:
+  Power node id that is used to uniquely identify the node for Xilinx
+  Power Management. The value is then passed to Xilinx platform
+  manager for power on/off and access.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  mboxes:
+description:
+  Array of phandles that describe the rx and tx for xilinx zynqmp
+  mailbox driver. order of rx and tx is described by the mbox-names
+  property. This will be used for communication with remote
+  processor.
+maxItems: 2
+
+  mbox-names:
+description:
+  Array of strings that denote which item in the mboxes property array
+  are the rx and tx for xilinx zynqmp mailbox driver
+maxItems: 2
+$ref: /schemas/types.yaml#/definitions/string-array
+
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+
+  rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+   no-map;
+   reg = <0x3ed4 0x4000>;
+  };
+  rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+   no-map;
+   reg = <0x3ed44000 0x4000>;
+  };
+  rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+   no-map;
+   reg = <0x3ed48000 0x10>;
+  };
+
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes or label as disabled in
+  * status property
+  */
+ tcm0a: tcm_0a@ffe0 {
+ reg = <0xffe0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ phandle = <0x40>;
+ };
+ tcm0b: tcm_1a@ffe2 {
+ reg = <0xffe2 0x1>;
+ pnode-id = <0x10>;
+ no-map;
+ status = "okay";
+ phandle = <0x41>;
+ };
+
+ rpu {
+  compatible = "xlnx,zynqmp-r5-remoteproc";
+  #address-cells = <1>;
+

[PATCH v20 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-10-30 Thread Ben Levinsky
Update as follows:

Xilinx R5 Device Tree Bindings
- update typos and style
- add compat string for singular r5 core to accomodate
  devm_of_platform_populate


Remoteproc Driver:
- remove zynqmp_r5_rproc::dt_node and replace usage with
  zynqmp_r5_rproc->dev->of_node throughout file
- emulate TI K3 R5 probe use of devm_of_platform_populate to set devices for
  each R5 core's corresponding remoteproc device
- replace zynqmp_r5_rproc var name 'core' to 'z_rproc' throughout file for
  consistency
- update indentation
- remove unused var in zynqmp_r5_remoteproc_probe
- update typo in Kconfig


Previous version 
https://patchwork.kernel.org/project/linux-remoteproc/list/?series=367125

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 143 
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 771 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1079 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v20 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-10-30 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v19 3/5] firmware: xilinx: Add RPU configuration APIs

2020-10-19 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
v11:
- update usage of zynqmp_pm_get_rpu_mode to return rpu mode in enum
- update zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode arguments to 
remove unused args
v12:
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn arg's to
  reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v19 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-10-19 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
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
v9:
- zynqmp_pm_force_powerdown update arg 'target' to 'node'
- zynqmp_pm_request_wakeup fix code style
v10:
- add types.h to includes for compilation
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v19 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-10-19 Thread Ben Levinsky
 prints to not use carriage return, just
  newline
- zynqmp_r5_remoteproc: look up tcm banks via property instead of string
  name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
- device tree binding r5 node to have link to TCMs via
  meta-memory-regions property
- fix device tree binding so no warnings from 'make dt_binding_check'
v12:
- update signed off by so that latest developer name is last
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn
  arg's to reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
v13:
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
v14:
- rebase off v5.9-rc3 kernel
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- in device tree binding place IPC nodes in RAM in the
  reserved memory section
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_probe as there is static
  allocation already
- error at probe time if lockstep-mode property not present in device tree
- update commit message as per review
- remove dependency on MAILBOX in makefile as ZYNQMP_IPI_MBOX is present
- remove unused macros
- update comment ordering of zynqmp_r5_pdata to match struct definition
- zynqmp_r5_remoteproc::tcm_mem_release error if pnode id is invalid
- remove obsolete TODOs
- only call zynqmp_r5_remoteproc::zynqmp_r5_probe if the index is valid
- remove uneven dev_dbg/dev_err fn calls
v15:
- change lockstep mode device tree property from acting as
  boolean, to instead being used as, if it is present, then r5 is in
  lockstep mode. otherwise in split.
- add safeguard for if 2 rpu remoteproc instances are provided then err out
v16:
- replace of_get_property(dev->of_node, "lockstep-mode" with
  of_property_read_bool
- propagate rpu mode specified in device tree through functions instead
  of holding a global, static var
- check child remoteproc nodes via of_get_available_child_count before
  looping through children
- replace check of "pdata->pnode_id == 0" instead by checking rpu's
  zynqmp_r5_pdata* if NULL
- remove old, obsolete checks for dma_pools in zynqmp_r5_remoteproc_remove
- change rpus from zynqmp_r5_pdata[] to zynqmp_r5_pdata*[] so that
  check for pdata->pnode_id == 0 is not needed
v17:
- remove compatible string from tcm bank nodes
- fix style for bindings
- add boolean type to lockstep mode in binding
- add/update descriptions memory-region, meta-memory-regions,
  pnode-id, mbox* properties
- update driver as per kernel-test-robot
v18:
- *really* change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- to more closely mimic other remoteproc drivers, change zynqmp r5 rproc
  data from zynqmp_r5_pdata to zynqmp_r5_rproc and pdata local var to
  zproc
- remove global vars rpus and rpu_mode
- instantiate device for zynqmp r5 rproc from device set by rproc_alloc
- fix typos
- update to call zynqmp_r5_release from the rproc_alloc-related device and
  remove the instantiated device from zynqmp_r5_probe
- remove unneeded call to platform_set_drvdata
- remove driver remove function, as the clean up is handled in release
- remove while (!skb_queue_empty loop and mbox_free_channel calls in 
  zynqmp_r5_release, and mbox_free_channel
- remove device_unregister call in zynqmp_r5_release
- remove kzalloc for pdata (what is now called z_rproc)
- update conditional in loop to calls of zynqmp_r5_probe
- update example remoteproc zynqmp r5 compat string, remove version
  number
v19:
- update bindings xilinx r5 remoteproc property from
  'memory-region' to 'memory-regions' as well as its usage
  in the driver
- add more comments/documentation for xilinx r5 remoteproc
  driver functions
- in z_rproc structure add linked list elem that is later used
  to keep track of house cleaning in driver remove and device tree
  node for mailbox client setup
- in zynqmp_r5_probe store in dt_node and dev pointer for later usage
  in mailbox client setup
- remove release, handle rproc and mbox cleanup in driver remove
  that is re-introduced
- zynqmp_r5_remoteproc.c::tcm_mem_release() remove unneeded check for
  negative value on a u32
- fix off-by-one error in bound checking for
  parse_mem_regions strlen
- fix checkpatch strict warnings for comments
- update tcm_mem_alloc bound check for TCM bank
  addresses

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU conf

[PATCH v19 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-19 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
v2:
 - remove domain struct as per review from Mathieu
v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
v11:
- use enums instead of u32 where possible in zynqmp_r5_remoteproc
- update usage of zynqmp_pm_set/get_rpu_mode and zynqmp_pm_set_tcm_config
- update prints to not use carriage return, just newline
- look up tcm banks via property in r5 node instead of string name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
v12:
- update signed off by so that latest developer name is last
- do not cast enums to u32s for zynqmp_pm* functions
v14:
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_prob

[PATCH v19 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-10-19 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v19 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-10-19 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
v11:
- add property meta-memory-regions to illustrate link
  between r5 and TCM banks
- update so no warnings from 'make dt_binding_check'
v14:
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- place IPC nodes in RAM in the reserved memory section
v15:
- change lockstep-mode prop as follows: if present, then RPU cluster is in
  lockstep mode. if not present, cluster is in split mode.
v17:
- remove compatible string from tcm bank nodes
- fix style for bindings
- add boolean type to lockstep mode in binding
- add/update descriptions memory-region, meta-memory-regions,
  pnode-id, mbox* properties
v18: 
- update example remoteproc zynqmp r5 compat string, remove version
  number
- change property from memory-region to memory-regions
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 142 ++
 1 file changed, 142 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..c202dca3b6d0
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: xlnx,zynqmp-r5-remoteproc
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+type: boolean
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-regions:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication. each carveout in this case should be in DDR, not
+  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  meta-memory-regions:
+description:
+  collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack.
+  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
+  BRAM, OCM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  pnode-id:
+maxItems: 1
+description:
+  power node id that is used to uniquely identify the node for Xilinx
+  Power Management. The value is then passed to Xilinx platform
+  manager for power on/off and access.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  mboxes:
+description:
+  array of phandles that describe the rx and tx for xilinx zynqmp
+  mailbox driver. order of rx and tx is described by the mbox-names
+  property. This will be used for communication with remote
+  processor.
+maxItems: 2
+
+  mbox-names:
+description:
+  array of strings that denote which item in the mboxes property array
+  are the rx and tx for xilinx z

RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-19 Thread Ben Levinsky
Hi Stefano,

Thanks for the review.

> -Original Message-
> From: Stefano Stabellini 
> Sent: Monday, October 19, 2020 1:44 PM
> To: Ben Levinsky 
> Cc: Ed T. Mooring ; sunnylian...@gmail.com;
> punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> Michal Simek ; michael.auch...@ni.com;
> devicet...@vger.kernel.org; mathieu.poir...@linaro.org; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> On Mon, 5 Oct 2020, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in different 2
> > configurations -
> > * split
> > * lock-step
> >
> > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > Platform Management Unit that handles the R5 configuration, memory
> access
> > and R5 lifecycle management. The interface to this manager is done in this
> > driver via zynqmp_pm_* function calls.
> 
> Mostly minor comments left
> 
> 
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ed Mooring 
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Ben Levinsky 
> > ---
> > v2:
> >  - remove domain struct as per review from Mathieu
> > v3:
> >  - add xilinx-related platform mgmt fn's instead of wrapping around
> >function pointer in xilinx eemi ops struct
> > v4:
> >  - add default values for enums
> >  - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1
> check
> >are still raised as each is due to fixing the warning results in that
> >  particular line going over 80 characters.
> > v5:
> >  - parse_fw change from use of rproc_of_resm_mem_entry_init to
> >  rproc_mem_entry_init and use of alloc/release
> >  - var's of type zynqmp_r5_pdata all have same local variable name
> >  - use dev_dbg instead of dev_info
> > v6:
> >  - adding memory carveouts is handled much more similarly. All mem
> >  carveouts are
> >now described in reserved memory as needed. That is, TCM nodes are not
> >coupled to remoteproc anymore. This is reflected in the remoteproc R5
> >  driver
> >and the device tree binding.
> >  - remove mailbox from device tree binding as it is not necessary for elf
> >loading
> >  - use lockstep-mode property for configuring RPU
> > v7:
> >  - remove unused headers
> >  - change  u32 *lockstep_mode ->  u32 lockstep_mode;
> >  - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
> >  - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
> >remoteproc-probe time
> >  - remove is_r5_mode_set from  zynqmp rpu remote processor private data
> >  - do not error out if no mailbox is provided
> >  - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
> >  pdata is
> >handled in zynqmp_r5_remoteproc_remove
> > v8:
> >  - remove old acks, reviewed-by's in commit message
> > v9:
> > - as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
> >   do not call skb_queue_empty
> > - update usage for zynqmp_pm_set_rpu_mode,
> zynqmp_pm_set_tcm_config and
> >   zynqmp_pm_get_rpu_mode
> > - update 5/5 patch commit message to document supported configurations
> >   and how they are booted by the driver.
> > - remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
> > - compilation warnings no longer raised
> > - remove unused includes from zynqmp_r5_remoteproc.c
> > - remove unused  var autoboot from zynqmp_r5_remoteproc.c
> > - reorder zynqmp_r5_pdata fpr small mem savings due to alignment
> > - use of zynqmp_pm_set_tcm_config now does not have
> >   output arg
> > - in tcm handling, unconditionally use &= 0x000f mask since all nodes
> >   in this fn are for tcm
> > - update comments for translating dma field in tcm handling to device
> >   address
> > - update calls to rproc_mem_entry_init in parse_mem_regions so that there
> >   are only 2 cases for types of carveouts instead of 3
> > - in parse_mem_regions, check if device tree node is null before using it
> > - add example device tree nodes used in parse_mem_regions and tcm
> parsing
> > - add comment for vring id node length
> > - add check for string length so that vring id is at least min length
> > - move tcm nodes from reserved mem to instead own device tree nodes
> >and only use 

RE: RE: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-15 Thread Ben Levinsky
Hi All,

> -Original Message-
> From: Michael Auchter 
> Sent: Tuesday, October 6, 2020 3:21 PM
> To: Ben Levinsky 
> Cc: Ed T. Mooring ; Stefano Stabellini
> ; Michal Simek ;
> devicet...@vger.kernel.org; mathieu.poir...@linaro.org; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: RE: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5
> remoteproc driver
> 
> On Tue, Oct 06, 2020 at 09:46:38PM +, Ben Levinsky wrote:
> >
> >
> > > -Original Message-
> > > From: Michael Auchter 
> > > Sent: Tuesday, October 6, 2020 2:32 PM
> > > To: Ben Levinsky 
> > > Cc: Ed T. Mooring ; sunnylian...@gmail.com;
> > > punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> > > Michal Simek ; devicet...@vger.kernel.org;
> > > mathieu.poir...@linaro.org; linux-remotep...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; robh...@kernel.org; linux-arm-
> > > ker...@lists.infradead.org
> > > Subject: Re: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5
> > > remoteproc driver
> > >
> > > On Tue, Oct 06, 2020 at 07:15:49PM +, Ben Levinsky wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > Thanks for the review
> > > >
> > >
> > > < ... snip ... >
> > >
> > > > > > +   z_rproc = rproc->priv;
> > > > > > +   z_rproc->dev.release = zynqmp_r5_release;
> > > > >
> > > > > This is the only field of z_rproc->dev that's actually initialized, 
> > > > > and
> > > > > this device is not registered with the core at all, so 
> > > > > zynqmp_r5_release
> > > > > will never be called.
> > > > >
> > > > > Since it doesn't look like there's a need to create this additional
> > > > > device, I'd suggest:
> > > > >   - Dropping the struct device from struct zynqmp_r5_rproc
> > > > >   - Performing the necessary cleanup in the driver remove
> > > > > callback instead of trying to tie it to device release
> > > >
> > > > For the most part I agree. I believe the device is still needed for
> > > > the mailbox client setup.
> > > >
> > > > As the call to mbox_request_channel_byname() requires its own device
> > > > that has the corresponding child node with the corresponding
> > > > mbox-related properties.
> > > >
> > > > With that in mind, is it still ok to keep the device node?
> > >
> > > Ah, I see. Thanks for the clarification!
> > >
> > > Instead of manually dealing with the device node creation for the
> > > individual processors, perhaps it makes more sense to use
> > > devm_of_platform_populate() to create them. This is also consistent with
> > > the way the TI K3 R5F remoteproc driver does things.
> > >
> > > Cheers,
> > >  Michael
> >
> > I've been working on this today for a way around it and found one that I
> think works with your initial suggestion,
> > - in z_rproc, change dev from struct device to struct device*
> > ^ the above is shown the usage thereof below. It is there for the
> mailbox setup.
> > - in driver probe:
> > - add list_head to keep track of each core's z_rproc and for the driver
> remove clean up
> > - in each core's probe (zynqmp_r5_probe) dothe following:
> >
> >
> >rproc_ptr = rproc_alloc(dev, dev_name(dev), _r5_rproc_ops,
> >   NULL, sizeof(struct 
> > zynqmp_r5_rproc));
> > if (!rproc_ptr)
> > return -ENOMEM;
> > z_rproc = rproc_ptr->priv;
> > z_rproc->dt_node = node;
> > z_rproc->rproc = rproc_ptr;
> > z_rproc->dev = _ptr->dev;
> > z_rproc->dev->of_node = node;
> > where node is the specific R5 core's of_node/ Device tree node.
> >
> > the above preserves most of the mailbox setup code.
> 
> I see how this works, but it feels a bit weird to me to be overriding
> the remoteproc dev's of_node ptr. Personally I find the
> devm_of_platform_populate() approach a bit less confusing.
> 
> But, it's also not my call to make ;). Perhaps a remoteproc maintainer
> can chime in here.
> 
> >

Ping for comments here.

I looked at the TI R5 remoteproc driver and from what I can see, it seems

RE: [PATCH v18 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-10-08 Thread Ben Levinsky
Hi Sorry there were some typos and errors in my response so I'll correct them 
below:

> -Original Message-
> From: Ben Levinsky 
> Sent: Thursday, October 8, 2020 7:21 AM
> To: Linus Walleij ; Catalin Marinas
> ; Stefano Stabellini ; Ed T.
> Mooring 
> Cc: Ed T. Mooring ; sunnylian...@gmail.com; Punit
> Agrawal ; Michal Simek
> ; michael.auch...@ni.com; open list:OPEN FIRMWARE
> AND FLATTENED DEVICE TREE BINDINGS ;
> Mathieu Poirier ; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob Herring
> ; Linux ARM 
> Subject: RE: [PATCH v18 4/5] dt-bindings: remoteproc: Add documentation for
> ZynqMP R5 rproc bindings
> 
> Hi Linus,
> 
> Thanks for the review
> 
> Please see my comments inline
> 
> >
> > Hi Ben,
> >
> > thanks for your patch! I noticed this today  and pay some interest
> > because in the past I used with implementing the support for
> > TCM memory on ARM32.
> >
> > On Mon, Oct 5, 2020 at 6:06 PM Ben Levinsky 
> > wrote:
> >
> > > Add binding for ZynqMP R5 OpenAMP.
> > >
> > > Represent the RPU domain resources in one device node. Each RPU
> > > processor is a subnode of the top RPU domain node.
> > >
> > > Signed-off-by: Jason Wu 
> > > Signed-off-by: Wendy Liang 
> > > Signed-off-by: Michal Simek 
> > > Signed-off-by: Ben Levinsky 
> > (...)
> >
> > > +title: Xilinx R5 remote processor controller bindings
> > > +
> > > +description:
> > > +  This document defines the binding for the remoteproc component that
> > loads and
> > > +  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> >
> > ... firmwares for the on-board Cortex R5 of the Zynqmp .. (etc)
> >
> Will fix
> > > +
> > > +  Note that the Linux has global addressing view of the R5-related
> memory
> > (TCM)
> > > +  so the absolute address ranges are provided in TCM reg's.
> >
> > Please do not refer to Linux in bindings, they are also for other
> > operating systems.
> >
> > Isn't that spelled out "Tightly Coupled Memory" (please expand the
> acronym).
> >
> > I had a hard time to parse this description, do you mean:
> >
> > "The Tightly Coupled Memory (an on-chip SRAM) used by the Cortex R5
> > is double-ported and visible in both the physical memory space of the
> > Cortex A5 and the memory space of the main ZynqMP processor
> > cluster. This is visible in the address space of the ZynqMP processor
> > at the address indicated here."
> >
> > That would make sense, but please confirm/update.
> >
> 
> Yes the TCM address space as noted in the TCM device tree nodes (e.g.
> 0xffe0) is visible at that address on the A53 cluster.  Will fix
> 
> > > +  memory-region:
> > > +description:
> > > +  collection of memory carveouts used for elf-loading and inter-
> processor
> > > +  communication. each carveout in this case should be in DDR, not
> > > +  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
> > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> >
> > This is nice, you're reusing the infrastructure we already
> > have for these carveouts, good design!
> >
> > > +  meta-memory-regions:
> > > +description:
> > > +  collection of memories that are not present in the top level memory
> > > +  nodes' mapping. For example, R5s' TCM banks. These banks are
> needed
> > > +  for R5 firmware meta data such as the R5 firmware's heap and stack.
> > > +  To be more precise, this is on-chip reserved SRAM regions, e.g. 
> > > TCM,
> > > +  BRAM, OCM, etc.
> > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> >
> > Is this in the memory space of the main CPU cluster?
> >
> > It sure looks like that.
> >
> 
> Yes this is in the memory space of the A53 cluster
> 
> Will fix to comment as such. Thank you
> 
> > > + /*
> > > +  * Below nodes are required if using TCM to load R5 firmware
> > > +  * if not, then either do not provide nodes are label as disabled in
> > > +  * status property
> > > +  */
> > > + tcm0a: tcm_0a@ffe0 {
> > > + reg = <0xffe0 0x1>;
> > > + pnode-id = <0xf>;
> > > + no-map;
> > > + status = "okay";
> > > + phandle = <0x40>;
> > > + };
&g

RE: [PATCH v18 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-10-08 Thread Ben Levinsky
Hi Linus, 

Thanks for the review

Please see my comments inline

> 
> Hi Ben,
> 
> thanks for your patch! I noticed this today  and pay some interest
> because in the past I used with implementing the support for
> TCM memory on ARM32.
> 
> On Mon, Oct 5, 2020 at 6:06 PM Ben Levinsky 
> wrote:
> 
> > Add binding for ZynqMP R5 OpenAMP.
> >
> > Represent the RPU domain resources in one device node. Each RPU
> > processor is a subnode of the top RPU domain node.
> >
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ben Levinsky 
> (...)
> 
> > +title: Xilinx R5 remote processor controller bindings
> > +
> > +description:
> > +  This document defines the binding for the remoteproc component that
> loads and
> > +  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> 
> ... firmwares for the on-board Cortex R5 of the Zynqmp .. (etc)
> 
Will fix
> > +
> > +  Note that the Linux has global addressing view of the R5-related memory
> (TCM)
> > +  so the absolute address ranges are provided in TCM reg's.
> 
> Please do not refer to Linux in bindings, they are also for other
> operating systems.
> 
> Isn't that spelled out "Tightly Coupled Memory" (please expand the acronym).
> 
> I had a hard time to parse this description, do you mean:
> 
> "The Tightly Coupled Memory (an on-chip SRAM) used by the Cortex R5
> is double-ported and visible in both the physical memory space of the
> Cortex A5 and the memory space of the main ZynqMP processor
> cluster. This is visible in the address space of the ZynqMP processor
> at the address indicated here."
> 
> That would make sense, but please confirm/update.
> 

Yes the TCM address space as noted in the TCM device tree nodes (e.g. 
0xffe0) is visible at that address on the A53 cluster.  Will fix

> > +  memory-region:
> > +description:
> > +  collection of memory carveouts used for elf-loading and 
> > inter-processor
> > +  communication. each carveout in this case should be in DDR, not
> > +  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> 
> This is nice, you're reusing the infrastructure we already
> have for these carveouts, good design!
> 
> > +  meta-memory-regions:
> > +description:
> > +  collection of memories that are not present in the top level memory
> > +  nodes' mapping. For example, R5s' TCM banks. These banks are needed
> > +  for R5 firmware meta data such as the R5 firmware's heap and stack.
> > +  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
> > +  BRAM, OCM, etc.
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> 
> Is this in the memory space of the main CPU cluster?
> 
> It sure looks like that.
> 

Yes this is in the memory space of the A53 cluster

Will fix to comment as such. Thank you

> > + /*
> > +  * Below nodes are required if using TCM to load R5 firmware
> > +  * if not, then either do not provide nodes are label as disabled in
> > +  * status property
> > +  */
> > + tcm0a: tcm_0a@ffe0 {
> > + reg = <0xffe0 0x1>;
> > + pnode-id = <0xf>;
> > + no-map;
> > + status = "okay";
> > + phandle = <0x40>;
> > + };
> > + tcm0b: tcm_1a@ffe2 {
> > + reg = <0xffe2 0x1>;
> > + pnode-id = <0x10>;
> > + no-map;
> > + status = "okay";
> > + phandle = <0x41>;
> > + };
> 
> All right so this looks suspicious to me. Please explain
> what we are seeing in those reg entries? Is this the address
> seen by the main CPU cluster?
> 
> Does it mean that the main CPU see the memory of the
> R5 as "some kind of TCM" and that TCM is physically
> mapped at 0xffe0 (ITCM) and 0xffe2 (DTCM)?
> 
> If the first is ITCM and the second DTCM that is pretty
> important to point out, since this reflects the harvard
> architecture properties of these two memory areas.
> 
> The phandle = thing I do not understand at all, but
> maybe there is generic documentation for it that
> I've missed?
> 
> Last time I checked (which was on the ARM32) the physical
> address of the ITCM and DTCM could be changed at
> runtime with CP15 instructions. I might be wrong
> about this, but if that (or something similar) is still the case
> you can't

RE: RE: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-07 Thread Ben Levinsky



> -Original Message-
> From: Michael Auchter 
> Sent: Tuesday, October 6, 2020 3:21 PM
> To: Ben Levinsky 
> Cc: Ed T. Mooring ; Stefano Stabellini
> ; Michal Simek ;
> devicet...@vger.kernel.org; mathieu.poir...@linaro.org; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: RE: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5
> remoteproc driver
> 
> On Tue, Oct 06, 2020 at 09:46:38PM +, Ben Levinsky wrote:
> >
> >
> > > -Original Message-
> > > From: Michael Auchter 
> > > Sent: Tuesday, October 6, 2020 2:32 PM
> > > To: Ben Levinsky 
> > > Cc: Ed T. Mooring ; sunnylian...@gmail.com;
> > > punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> > > Michal Simek ; devicet...@vger.kernel.org;
> > > mathieu.poir...@linaro.org; linux-remotep...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; robh...@kernel.org; linux-arm-
> > > ker...@lists.infradead.org
> > > Subject: Re: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5
> > > remoteproc driver
> > >
> > > On Tue, Oct 06, 2020 at 07:15:49PM +, Ben Levinsky wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > Thanks for the review
> > > >
> > >
> > > < ... snip ... >
> > >
> > > > > > +   z_rproc = rproc->priv;
> > > > > > +   z_rproc->dev.release = zynqmp_r5_release;
> > > > >
> > > > > This is the only field of z_rproc->dev that's actually initialized, 
> > > > > and
> > > > > this device is not registered with the core at all, so 
> > > > > zynqmp_r5_release
> > > > > will never be called.
> > > > >
> > > > > Since it doesn't look like there's a need to create this additional
> > > > > device, I'd suggest:
> > > > >   - Dropping the struct device from struct zynqmp_r5_rproc
> > > > >   - Performing the necessary cleanup in the driver remove
> > > > > callback instead of trying to tie it to device release
> > > >
> > > > For the most part I agree. I believe the device is still needed for
> > > > the mailbox client setup.
> > > >
> > > > As the call to mbox_request_channel_byname() requires its own device
> > > > that has the corresponding child node with the corresponding
> > > > mbox-related properties.
> > > >
> > > > With that in mind, is it still ok to keep the device node?
> > >
> > > Ah, I see. Thanks for the clarification!
> > >
> > > Instead of manually dealing with the device node creation for the
> > > individual processors, perhaps it makes more sense to use
> > > devm_of_platform_populate() to create them. This is also consistent with
> > > the way the TI K3 R5F remoteproc driver does things.
> > >
> > > Cheers,
> > >  Michael
> >
> > I've been working on this today for a way around it and found one that I
> think works with your initial suggestion,
> > - in z_rproc, change dev from struct device to struct device*
> > ^ the above is shown the usage thereof below. It is there for the
> mailbox setup.
> > - in driver probe:
> > - add list_head to keep track of each core's z_rproc and for the driver
> remove clean up
> > - in each core's probe (zynqmp_r5_probe) dothe following:
> >
> >
> >rproc_ptr = rproc_alloc(dev, dev_name(dev), _r5_rproc_ops,
> >   NULL, sizeof(struct 
> > zynqmp_r5_rproc));
> > if (!rproc_ptr)
> > return -ENOMEM;
> > z_rproc = rproc_ptr->priv;
> > z_rproc->dt_node = node;
> > z_rproc->rproc = rproc_ptr;
> > z_rproc->dev = _ptr->dev;
> > z_rproc->dev->of_node = node;
> > where node is the specific R5 core's of_node/ Device tree node.
> >
> > the above preserves most of the mailbox setup code.
> 
> I see how this works, but it feels a bit weird to me to be overriding
> the remoteproc dev's of_node ptr. Personally I find the
> devm_of_platform_populate() approach a bit less confusing.
> 
> But, it's also not my call to make ;). Perhaps a remoteproc maintainer
> can chime in here.
> 
Fair enough. The way I see this, there is still a need for a struct devic

RE: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-06 Thread Ben Levinsky



> -Original Message-
> From: Michael Auchter 
> Sent: Tuesday, October 6, 2020 2:32 PM
> To: Ben Levinsky 
> Cc: Ed T. Mooring ; sunnylian...@gmail.com;
> punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> Michal Simek ; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; robh...@kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5
> remoteproc driver
> 
> On Tue, Oct 06, 2020 at 07:15:49PM +, Ben Levinsky wrote:
> >
> > Hi Michael,
> >
> > Thanks for the review
> >
> 
> < ... snip ... >
> 
> > > > +   z_rproc = rproc->priv;
> > > > +   z_rproc->dev.release = zynqmp_r5_release;
> > >
> > > This is the only field of z_rproc->dev that's actually initialized, and
> > > this device is not registered with the core at all, so zynqmp_r5_release
> > > will never be called.
> > >
> > > Since it doesn't look like there's a need to create this additional
> > > device, I'd suggest:
> > >   - Dropping the struct device from struct zynqmp_r5_rproc
> > >   - Performing the necessary cleanup in the driver remove
> > > callback instead of trying to tie it to device release
> >
> > For the most part I agree. I believe the device is still needed for
> > the mailbox client setup.
> >
> > As the call to mbox_request_channel_byname() requires its own device
> > that has the corresponding child node with the corresponding
> > mbox-related properties.
> >
> > With that in mind, is it still ok to keep the device node?
> 
> Ah, I see. Thanks for the clarification!
> 
> Instead of manually dealing with the device node creation for the
> individual processors, perhaps it makes more sense to use
> devm_of_platform_populate() to create them. This is also consistent with
> the way the TI K3 R5F remoteproc driver does things.
> 
> Cheers,
>  Michael

I've been working on this today for a way around it and found one that I think 
works with your initial suggestion,
- in z_rproc, change dev from struct device to struct device*
^ the above is shown the usage thereof below. It is there for the 
mailbox setup.
- in driver probe:
- add list_head to keep track of each core's z_rproc and for the driver 
remove clean up
- in each core's probe (zynqmp_r5_probe) dothe following:


   rproc_ptr = rproc_alloc(dev, dev_name(dev), _r5_rproc_ops,
  NULL, sizeof(struct 
zynqmp_r5_rproc));
if (!rproc_ptr)
return -ENOMEM;
z_rproc = rproc_ptr->priv;
z_rproc->dt_node = node;
z_rproc->rproc = rproc_ptr;
z_rproc->dev = _ptr->dev;
z_rproc->dev->of_node = node; 
where node is the specific R5 core's of_node/ Device tree node.

the above preserves most of the mailbox setup code.


With this, I have already successfully done the following in a v19 patch
- move all the previous driver release code to remove
- able to probe, start/stop r5, driver remove repeatedly

Also, this mimics the TI R5 driver code as each core's rproc has a list_head 
and they have a structure for the cluster which among other things maintains a 
linked list of the cores' specific rproc information.

Thanks
Ben


RE: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-06 Thread Ben Levinsky


Hi Michael,

Thanks for the review

> -Original Message-
> From: Michael Auchter 
> Sent: Monday, October 5, 2020 12:35 PM
> To: Ben Levinsky 
> Cc: Ed T. Mooring ; sunnylian...@gmail.com;
> punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> Michal Simek ; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; robh...@kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hey Ben,
> 
> On Mon, Oct 05, 2020 at 09:06:14AM -0700, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in different 2
> > configurations -
> > * split
> > * lock-step
> >
> > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > Platform Management Unit that handles the R5 configuration, memory
> access
> > and R5 lifecycle management. The interface to this manager is done in this
> > driver via zynqmp_pm_* function calls.
> >
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ed Mooring 
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Ben Levinsky 
> > ---
> > v2:
> >  - remove domain struct as per review from Mathieu
> > v3:
> >  - add xilinx-related platform mgmt fn's instead of wrapping around
> >function pointer in xilinx eemi ops struct
> > v4:
> >  - add default values for enums
> >  - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1
> check
> >are still raised as each is due to fixing the warning results in that
> >  particular line going over 80 characters.
> > v5:
> >  - parse_fw change from use of rproc_of_resm_mem_entry_init to
> >  rproc_mem_entry_init and use of alloc/release
> >  - var's of type zynqmp_r5_pdata all have same local variable name
> >  - use dev_dbg instead of dev_info
> > v6:
> >  - adding memory carveouts is handled much more similarly. All mem
> >  carveouts are
> >now described in reserved memory as needed. That is, TCM nodes are not
> >coupled to remoteproc anymore. This is reflected in the remoteproc R5
> >  driver
> >and the device tree binding.
> >  - remove mailbox from device tree binding as it is not necessary for elf
> >loading
> >  - use lockstep-mode property for configuring RPU
> > v7:
> >  - remove unused headers
> >  - change  u32 *lockstep_mode ->  u32 lockstep_mode;
> >  - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
> >  - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
> >remoteproc-probe time
> >  - remove is_r5_mode_set from  zynqmp rpu remote processor private data
> >  - do not error out if no mailbox is provided
> >  - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
> >  pdata is
> >handled in zynqmp_r5_remoteproc_remove
> > v8:
> >  - remove old acks, reviewed-by's in commit message
> > v9:
> > - as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
> >   do not call skb_queue_empty
> > - update usage for zynqmp_pm_set_rpu_mode,
> zynqmp_pm_set_tcm_config and
> >   zynqmp_pm_get_rpu_mode
> > - update 5/5 patch commit message to document supported configurations
> >   and how they are booted by the driver.
> > - remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
> > - compilation warnings no longer raised
> > - remove unused includes from zynqmp_r5_remoteproc.c
> > - remove unused  var autoboot from zynqmp_r5_remoteproc.c
> > - reorder zynqmp_r5_pdata fpr small mem savings due to alignment
> > - use of zynqmp_pm_set_tcm_config now does not have
> >   output arg
> > - in tcm handling, unconditionally use &= 0x000f mask since all nodes
> >   in this fn are for tcm
> > - update comments for translating dma field in tcm handling to device
> >   address
> > - update calls to rproc_mem_entry_init in parse_mem_regions so that there
> >   are only 2 cases for types of carveouts instead of 3
> > - in parse_mem_regions, check if device tree node is null before using it
> > - add example device tree nodes used in parse_mem_regions and tcm
> parsing
> > - add comment for vring id node length
> > - add check for string length so that vring id is at least min length
> > - move tcm nodes from reserved mem to instead own device tree nodes
> >and only use them if 

[PATCH v18 3/5] firmware: xilinx: Add RPU configuration APIs

2020-10-05 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
v11:
- update usage of zynqmp_pm_get_rpu_mode to return rpu mode in enum
- update zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode arguments to 
remove unused args
v12:
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn arg's to
  reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v18 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-10-05 Thread Ben Levinsky
 prints to not use carriage return, just
  newline
- zynqmp_r5_remoteproc: look up tcm banks via property instead of string
  name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
- device tree binding r5 node to have link to TCMs via
  meta-memory-regions property
- fix device tree binding so no warnings from 'make dt_binding_check'
v12:
- update signed off by so that latest developer name is last
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn
  arg's to reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
v13:
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
v14:
- rebase off v5.9-rc3 kernel
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- in device tree binding, place IPC nodes in RAM in the reserved memory section
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_probe as there is static
  allocation already
- error at probe time if lockstep-mode property not present in device tree
- update commit message as per review
- remove dependency on MAILBOX in makefile as ZYNQMP_IPI_MBOX is present
- remove unused macros
- update comment ordering of zynqmp_r5_pdata to match struct definition
- zynqmp_r5_remoteproc::tcm_mem_release error if pnode id is invalid
- remove obsolete TODOs
- only call zynqmp_r5_remoteproc::zynqmp_r5_probe if the index is valid
- remove uneven dev_dbg/dev_err fn calls
v15:
- change lockstep mode device tree property from acting as
  boolean, to instead being used as, if it is present, then r5 is in lockstep 
mode. otherwise in split.
- add safeguard for if 2 rpu remoteproc instances are provided then err out
v16:
- replace of_get_property(dev->of_node, "lockstep-mode" with
  of_property_read_bool
- propagate rpu mode specified in device tree through functions instead
  of holding a global, static var
- check child remoteproc nodes via of_get_available_child_count before
  looping through children
- replace check of "pdata->pnode_id == 0" instead by checking rpu's
  zynqmp_r5_pdata* if NULL
- remove old, obsolete checks for dma_pools in zynqmp_r5_remoteproc_remove
- change rpus from zynqmp_r5_pdata[] to zynqmp_r5_pdata*[] so that
  check for pdata->pnode_id == 0 is not needed
v17:
- remove compatible string from tcm bank nodes
- fix style for bindings
- add boolean type to lockstep mode in binding
- add/update descriptions memory-region, meta-memory-regions,
  pnode-id, mbox* properties
- update driver as per kernel-test-robot
v18:
- *really* change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- to more closely mimic other remoteproc drivers, change zynqmp r5 rproc
  data from zynqmp_r5_pdata to zynqmp_r5_rproc and pdata local var to
  zproc
- remove global vars rpus and rpu_mode
- instantiate device for zynqmp r5 rproc from device set by rproc_alloc
- fix typos
- update to call zynqmp_r5_release from the rproc_alloc-related device and
  remove the instantiated device from zynqmp_r5_probe
- remove unneeded call to platform_set_drvdata
- remove driver remove function, as the clean up is handled in release
- remove while (!skb_queue_empty loop and mbox_free_channel calls in 
  zynqmp_r5_release, and mbox_free_channel
- remove device_unregister call in zynqmp_r5_release
- remove kzalloc for pdata (what is now called z_rproc)
- update conditional in loop to calls of zynqmp_r5_probe
- update example remoteproc zynqmp r5 compat string, remove version
  number




Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 142 
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 708 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1015 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v18 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-10-05 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v18 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-10-05 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v18 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-10-05 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
v11:
- add property meta-memory-regions to illustrate link
  between r5 and TCM banks
- update so no warnings from 'make dt_binding_check'
v14:
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- place IPC nodes in RAM in the reserved memory section
v15:
- change lockstep-mode prop as follows: if present, then RPU cluster is in
  lockstep mode. if not present, cluster is in split mode.
v17:
- remove compatible string from tcm bank nodes
- fix style for bindings
- add boolean type to lockstep mode in binding
- add/update descriptions memory-region, meta-memory-regions,
  pnode-id, mbox* properties
v18: 
- update example remoteproc zynqmp r5 compat string, remove version
  number
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 142 ++
 1 file changed, 142 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..c202dca3b6d0
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: xlnx,zynqmp-r5-remoteproc
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+type: boolean
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-region:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication. each carveout in this case should be in DDR, not
+  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  meta-memory-regions:
+description:
+  collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack.
+  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
+  BRAM, OCM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  pnode-id:
+maxItems: 1
+description:
+  power node id that is used to uniquely identify the node for Xilinx
+  Power Management. The value is then passed to Xilinx platform
+  manager for power on/off and access.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  mboxes:
+description:
+  array of phandles that describe the rx and tx for xilinx zynqmp
+  mailbox driver. order of rx and tx is described by the mbox-names
+  property. This will be used for communication with remote
+  processor.
+maxItems: 2
+
+  mbox-names:
+description:
+  array of strings that denote which item in the mboxes property array
+  are the rx and tx for xilinx zynqmp mailbox driver
+maxItems: 2
+$ref:

[PATCH v18 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-05 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
v2:
 - remove domain struct as per review from Mathieu
v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
v11:
- use enums instead of u32 where possible in zynqmp_r5_remoteproc
- update usage of zynqmp_pm_set/get_rpu_mode and zynqmp_pm_set_tcm_config
- update prints to not use carriage return, just newline
- look up tcm banks via property in r5 node instead of string name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
v12:
- update signed off by so that latest developer name is last
- do not cast enums to u32s for zynqmp_pm* functions
v14:
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_prob

RE: [PATCH v17 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-02 Thread Ben Levinsky
Hi Michael, 

Thanks for the review. With the numerous sets of review, I think a few things 
got lost along the way that I will make sure to get encompassed in the next 
revision

- in bindings example, remove the '-1.0'
- remove the global rpu_mode var
^ the above I had thought was in v16 so sorry about that...

Otherwise I will fix up the memory management that is occurring in the driver 
as you describe.

Again thank you!
Ben

> -Original Message-
> From: Michael Auchter 
> Sent: Friday, October 2, 2020 11:59 AM
> To: Ben Levinsky 
> Cc: sunnylian...@gmail.com; punit1.agra...@toshiba.co.jp; Stefano Stabellini
> ; Michal Simek ;
> devicet...@vger.kernel.org; mathieu.poir...@linaro.org; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v17 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hey Ben,
> 
> On Thu, Oct 01, 2020 at 02:05:41PM -0700, Ben Levinsky wrote:
> > R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> > remotproc driver, we can boot the R5 sub-system in different 2
> > configurations -
> > * split
> > * lock-step
> >
> > The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> > Platform Management Unit that handles the R5 configuration, memory
> access
> > and R5 lifecycle management. The interface to this manager is done in this
> > driver via zynqmp_pm_* function calls.
> >
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ed Mooring 
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Ben Levinsky 
> > Reported-by: kernel test robot 
> > ---
> > v2:
> >  - remove domain struct as per review from Mathieu
> >  v3:
> >  - add xilinx-related platform mgmt fn's instead of wrapping around
> >function pointer in xilinx eemi ops struct
> >  v4:
> >  - add default values for enums
> >  - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1
> check
> >are still raised as each is due to fixing the warning results in that
> >  particular line going over 80 characters.
> >  v5:
> >  - parse_fw change from use of rproc_of_resm_mem_entry_init to
> >  rproc_mem_entry_init and use of alloc/release
> >  - var's of type zynqmp_r5_pdata all have same local variable name
> >  - use dev_dbg instead of dev_info
> >  v6:
> >  - adding memory carveouts is handled much more similarly. All mem
> >  carveouts are
> >now described in reserved memory as needed. That is, TCM nodes are not
> >coupled to remoteproc anymore. This is reflected in the remoteproc R5
> >  driver
> >and the device tree binding.
> >  - remove mailbox from device tree binding as it is not necessary for elf
> >loading
> >  - use lockstep-mode property for configuring RPU
> >  v7:
> >  - remove unused headers
> >  - change  u32 *lockstep_mode ->  u32 lockstep_mode;
> >  - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
> >  - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
> >remoteproc-probe time
> >  - remove is_r5_mode_set from  zynqmp rpu remote processor private data
> >  - do not error out if no mailbox is provided
> >  - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
> >  pdata is
> >handled in zynqmp_r5_remoteproc_remove
> > v8:
> >  - remove old acks, reviewed-by's in commit message
> > v9:
> > - as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
> >   do not call skb_queue_empty
> > - update usage for zynqmp_pm_set_rpu_mode,
> zynqmp_pm_set_tcm_config and
> >   zynqmp_pm_get_rpu_mode
> > - update 5/5 patch commit message to document supported configurations
> >   and how they are booted by the driver.
> > - remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
> > - compilation warnings no longer raised
> > - remove unused includes from zynqmp_r5_remoteproc.c
> > - remove unused  var autoboot from zynqmp_r5_remoteproc.c
> > - reorder zynqmp_r5_pdata fpr small mem savings due to alignment
> > - use of zynqmp_pm_set_tcm_config now does not have
> >   output arg
> > - in tcm handling, unconditionally use &= 0x000f mask since all nodes
> >   in this fn are for tcm
> > - update comments for translating dma field in tcm handling to device
> >   address
> > - update calls to rproc_mem_entry_init in parse_mem_regions so that there
> >   are only 2 cases for types of carveo

[PATCH v17 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-10-01 Thread Ben Levinsky
 prints to not use carriage return, just
  newline
- zynqmp_r5_remoteproc: look up tcm banks via property instead of string
  name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
- device tree binding r5 node to have link to TCMs via
  meta-memory-regions property
- fix device tree binding so no warnings from 'make dt_binding_check'
v12:
- update signed off by so that latest developer name is last
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn
  arg's to reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
v13:
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
v14:
- rebase off v5.9-rc3 kernel
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- in device tree binding, place IPC nodes in RAM in the reserved memory section
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_probe as there is static
  allocation already
- error at probe time if lockstep-mode property not present in device tree
- update commit message as per review
- remove dependency on MAILBOX in makefile as ZYNQMP_IPI_MBOX is present
- remove unused macros
- update comment ordering of zynqmp_r5_pdata to match struct definition
- zynqmp_r5_remoteproc::tcm_mem_release error if pnode id is invalid
- remove obsolete TODOs
- only call zynqmp_r5_remoteproc::zynqmp_r5_probe if the index is valid
- remove uneven dev_dbg/dev_err fn calls
v15:
- change lockstep mode device tree property from acting as
  boolean, to instead being used as, if it is present, then r5 is in lockstep 
mode. otherwise in split.
- add safeguard for if 2 rpu remoteproc instances are provided then err out
v16:
- replace of_get_property(dev->of_node, "lockstep-mode" with
  of_property_read_bool
- propagate rpu mode specified in device tree through functions instead
  of holding a global, static var
- check child remoteproc nodes via of_get_available_child_count before
  looping through children
- replace check of "pdata->pnode_id == 0" instead by checking rpu's
  zynqmp_r5_pdata* if NULL
- remove old, obsolete checks for dma_pools in zynqmp_r5_remoteproc_remove
- change rpus from zynqmp_r5_pdata[] to zynqmp_r5_pdata*[] so that
  check for pdata->pnode_id == 0 is not needed
v17:
- remove compatible string from tcm bank nodes
- fix style for bindings
- add boolean type to lockstep mode in binding
- add/update descriptions memory-region, meta-memory-regions,
  pnode-id, mbox* properties
- update driver as per kernel-test-robot

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 142 
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 778 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1085 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v17 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-10-01 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
Reported-by: kernel test robot 
---
v2:
 - remove domain struct as per review from Mathieu
 v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
 v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
 v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
 v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
 v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
v11:
- use enums instead of u32 where possible in zynqmp_r5_remoteproc
- update usage of zynqmp_pm_set/get_rpu_mode and zynqmp_pm_set_tcm_config
- update prints to not use carriage return, just newline
- look up tcm banks via property in r5 node instead of string name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
v12:
- update signed off by so that latest developer name is last
- do not cast enums to u32s for zynqmp_pm* functions
v14:
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r

[PATCH v17 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-10-01 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
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
v9:
- zynqmp_pm_force_powerdown update arg 'target' to 'node'
- zynqmp_pm_request_wakeup fix code style
v10:
- add types.h to includes for compilation
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v17 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-10-01 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---

 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v17 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-10-01 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
v11:
- add property meta-memory-regions to illustrate link
  between r5 and TCM banks
- update so no warnings from 'make dt_binding_check'
v14:
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- place IPC nodes in RAM in the reserved memory section
v15:
- change lockstep-mode prop as follows: if present, then RPU cluster is in
  lockstep mode. if not present, cluster is in split mode.
v17:
- remove compatible string from tcm bank nodes
- fix style for bindings
- add boolean type to lockstep mode in binding
- add/update descriptions memory-region, meta-memory-regions,
  pnode-id, mbox* properties
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 142 ++
 1 file changed, 142 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..3982be2051dd
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: xlnx,zynqmp-r5-remoteproc
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+type: boolean
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-region:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication. each carveout in this case should be in DDR, not
+  chip-specific memory. In Xilinx case, this is TCM, OCM, BRAM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  meta-memory-regions:
+description:
+  collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack.
+  To be more precise, this is on-chip reserved SRAM regions, e.g. TCM,
+  BRAM, OCM, etc.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+
+  pnode-id:
+maxItems: 1
+description:
+  power node id that is used to uniquely identify the node for Xilinx
+  Power Management. The value is then passed to Xilinx platform
+  manager for power on/off and access.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  mboxes:
+description:
+  array of phandles that describe the rx and tx for xilinx zynqmp
+  mailbox driver. order of rx and tx is described by the mbox-names
+  property. This will be used for communication with remote
+  processor.
+maxItems: 2
+
+  mbox-names:
+description:
+  array of strings that denote which item in the mboxes property array
+  are the rx and tx for xilinx zynqmp mailbox driver
+maxItems: 2
+$ref: /schemas/types.yaml#/definitions/string-array
+
+
+examples:
+  - |
+ reserved-memory {

[PATCH v17 3/5] firmware: xilinx: Add RPU configuration APIs

2020-10-01 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
v11:
- update usage of zynqmp_pm_get_rpu_mode to return rpu mode in enum
- update zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode arguments to 
remove unused args
v12:
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn arg's to
  reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



RE: [PATCH v16 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-09-30 Thread Ben Levinsky
Hi Rob,

> -Original Message-
> From: Rob Herring 
> Sent: Tuesday, September 29, 2020 11:36 AM
> To: Ben Levinsky 
> Cc: Stefano Stabellini ; Michal Simek
> ; michael.auch...@ni.com; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Jason Wu ; Jiaying Liang
> ; Michal Simek 
> Subject: Re: [PATCH v16 4/5] dt-bindings: remoteproc: Add documentation for
> ZynqMP R5 rproc bindings
> 
> On Tue, Sep 22, 2020 at 03:39:29PM -0700, Ben Levinsky wrote:
> > Add binding for ZynqMP R5 OpenAMP.
> >
> > Represent the RPU domain resources in one device node. Each RPU
> > processor is a subnode of the top RPU domain node.
> >
> > Signed-off-by: Jason Wu 
> > Signed-off-by: Wendy Liang 
> > Signed-off-by: Michal Simek 
> > Signed-off-by: Ben Levinsky 
> > ---
> > v3:
> > - update zynqmp_r5 yaml parsing to not raise warnings for extra
> >   information in children of R5 node. The warning "node has a unit
> >   name, but no reg or ranges property" will still be raised though
> >   as this particular node is needed to describe the
> >   '#address-cells' and '#size-cells' information.
> > v4::
> > - remove warning '/example-0/rpu@ff9a/r5@0:
> >   node has a unit name, but no reg or ranges property'
> >   by adding reg to r5 node.
> > v5:
> > - update device tree sample and yaml parsing to not raise any warnings
> > - description for memory-region in yaml parsing
> > - compatible string in yaml parsing for TCM
> > v6:
> > - remove coupling TCM nodes with remoteproc
> > - remove mailbox as it is optional not needed
> > v7:
> > - change lockstep-mode to xlnx,cluster-mode
> > v9:
> > - show example IPC nodes and tcm bank nodes
> > v11:
> > - add property meta-memory-regions to illustrate link
> >   between r5 and TCM banks
> > - update so no warnings from 'make dt_binding_check'
> > v14:
> > - concerns were raised about the new property meta-memory-regions.
> >   There is no clear direction so for the moment I kept it in the series
> > - place IPC nodes in RAM in the reserved memory section
> > v15:
> > - change lockstep-mode prop as follows: if present, then RPU cluster is in
> >   lockstep mode. if not present, cluster is in split mode.
> > ---
> >  .../xilinx,zynqmp-r5-remoteproc.yaml  | 120 ++
> >  1 file changed, 120 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-
> r5-remoteproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml
> > new file mode 100644
> > index ..ce02e425692e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml
> > @@ -0,0 +1,120 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-
> remoteproc.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Xilinx R5 remote processor controller bindings
> > +
> > +description:
> > +  This document defines the binding for the remoteproc component that
> loads and
> > +  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> > +
> > +  Note that the Linux has global addressing view of the R5-related memory
> (TCM)
> > +  so the absolute address ranges are provided in TCM reg's.
> 
> blank line needed.
> 
will fix in next rev.
> TCMs specifically I'm concerned about how they are represented in system
> DT and here...
> 
So System DT can tie in with lopper plugin/assists so that TCMs are output to 
whatever the linux driver expects. 
> > +maintainers:
> > +  - Ed Mooring 
> > +  - Ben Levinsky 
> > +
> > +properties:
> > +  compatible:
> > +const: "xlnx,zynqmp-r5-remoteproc-1.0"
> 
> Don't need quotes.
> 
will fix in next rev.
> The use of version numbers was allowed for Xilinx programmable IP. I
> don't think this falls into that category.
> 
will fix in next rev.
> > +
> > +  lockstep-mode:
> > +description:
> > +  If this property is present, then the configuration is lock-step.
> 
> boolean...
> 
By this comment do you mean you want this to change or mention that it is 
implicit

[PATCH v16 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-22 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
v2:
 - remove domain struct as per review from Mathieu
 v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
 v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
 v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
 v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
 v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
v11:
- use enums instead of u32 where possible in zynqmp_r5_remoteproc
- update usage of zynqmp_pm_set/get_rpu_mode and zynqmp_pm_set_tcm_config
- update prints to not use carriage return, just newline
- look up tcm banks via property in r5 node instead of string name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
v12:
- update signed off by so that latest developer name is last
- do not cast enums to u32s for zynqmp_pm* functions
v14:
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_re

[PATCH v16 3/5] firmware: xilinx: Add RPU configuration APIs

2020-09-22 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
v11:
- update usage of zynqmp_pm_get_rpu_mode to return rpu mode in enum
- update zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode arguments to 
remove unused args
v12:
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn arg's to
  reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v16 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-09-22 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ben Levinsky 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
v11:
- add property meta-memory-regions to illustrate link
  between r5 and TCM banks
- update so no warnings from 'make dt_binding_check'
v14:
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- place IPC nodes in RAM in the reserved memory section
v15:
- change lockstep-mode prop as follows: if present, then RPU cluster is in
  lockstep mode. if not present, cluster is in split mode.
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 120 ++
 1 file changed, 120 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..ce02e425692e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: "xlnx,zynqmp-r5-remoteproc-1.0"
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-region:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication.
+maxItems: 4
+minItems: 4
+  meta-memory-regions:
+description:
+  collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack
+  pnode-id:
+maxItems: 1
+  mboxes:
+maxItems: 2
+  mbox-names:
+maxItems: 2
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+
+  rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+   no-map;
+   reg = <0x3ed4 0x4000>;
+  };
+  rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+   no-map;
+   reg = <0x3ed44000 0x4000>;
+  };
+  rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+   no-map;
+   reg = <0x3ed48000 0x10>;
+  };
+
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes are label as disabled in
+  * status property
+  */
+ tcm0a: tcm_0a@ffe0 {
+ reg = <0xffe0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ phandle = <0x40>;
+ compatible = "xlnx,tcm";
+ };
+ tcm0b: tcm_1a@ffe2 {
+ reg = <0xffe2 0x1>;
+ pnode-id = <0x10>;
+ no

[PATCH v16 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-09-22 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
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
v9:
- zynqmp_pm_force_powerdown update arg 'target' to 'node'
- zynqmp_pm_request_wakeup fix code style
v10:
- add types.h to includes for compilation
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v16 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-09-22 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v16 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-09-22 Thread Ben Levinsky
 prints to not use carriage return, just
  newline
- zynqmp_r5_remoteproc: look up tcm banks via property instead of string
  name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
- device tree binding r5 node to have link to TCMs via
  meta-memory-regions property
- fix device tree binding so no warnings from 'make dt_binding_check'
v12:
- update signed off by so that latest developer name is last
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn
  arg's to reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
v13:
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
v14:
- rebase off v5.9-rc3 kernel
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- in device tree binding, place IPC nodes in RAM in the reserved memory section
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_probe as there is static
  allocation already
- error at probe time if lockstep-mode property not present in device tree
- update commit message as per review
- remove dependency on MAILBOX in makefile as ZYNQMP_IPI_MBOX is present
- remove unused macros
- update comment ordering of zynqmp_r5_pdata to match struct definition
- zynqmp_r5_remoteproc::tcm_mem_release error if pnode id is invalid
- remove obsolete TODOs
- only call zynqmp_r5_remoteproc::zynqmp_r5_probe if the index is valid
- remove uneven dev_dbg/dev_err fn calls
v15:
- change lockstep mode device tree property from acting as
  boolean, to instead being used as, if it is present, then r5 is in lockstep 
mode. otherwise in split.
- add safeguard for if 2 rpu remoteproc instances are provided then err out



Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 120 +++
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 777 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1062 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



RE: [PATCH v15 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-22 Thread Ben Levinsky
Hi Michael,

> -Original Message-
> From: Michael Auchter 
> Sent: Monday, September 21, 2020 3:12 PM
> To: Ben Levinsky 
> Cc: sunnylian...@gmail.com; punit1.agra...@toshiba.co.jp; Stefano Stabellini
> ; Michal Simek ;
> devicet...@vger.kernel.org; mathieu.poir...@linaro.org; Ed T. Mooring
> ; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; robh...@kernel.org; linux-arm-
> ker...@lists.infradead.org; Jiaying Liang ; Michal Simek
> ; Ed T. Mooring ; Jason Wu
> 
> Subject: Re: [PATCH v15 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hey Ben,
> 
> Thanks for sending out the new series, this patchset is functional for
> booting both R5 0 and R5 1 in split mode.
> 
> A few comments below, still working my way through the rest of the code
> though now that this works.
> 
> On Mon, Sep 21, 2020 at 09:14:06AM -0700, Ben Levinsky wrote:
> <...>
> > +static int zynqmp_r5_remoteproc_probe(struct platform_device *pdev)
> > +{
> > +   int ret, i = 0;
> > +   struct device *dev = >dev;
> > +   struct device_node *nc;
> > +
> > +   rpu_mode =  of_get_property(dev->of_node, "lockstep-mode", NULL)
> ?
> > +   PM_RPU_MODE_LOCKSTEP : PM_RPU_MODE_SPLIT;
> 
> Extra whitespace, and of_property_read_bool would read a bit nicer here
> (does the same thing in the end, though).
> 
> Since rpu_mode is only used here and in r5_set_mode, I think it'd be
> better to plumb it through zynqmp_r5_probe instead of making it global
> in this file.
> 
[Ben Levinsky] will do
> > +
> > +   dev_dbg(dev, "RPU configuration: %s\n",
> > +   rpu_mode == PM_RPU_MODE_LOCKSTEP ? "lockstep" :
> "split");
> > +
> > +   for_each_available_child_of_node(dev->of_node, nc) {
> > +   /*
> > +* if 2 RPUs provided but one is lockstep, then we have an
> > +* invalid configuration.
> > +*/
> > +   if (i > 0 && rpu_mode == PM_RPU_MODE_LOCKSTEP)
> > +   return -EINVAL;
> > +
> > +   /* only call zynqmp_r5_probe if proper # of rpu's */
> > +   ret = (i < MAX_RPROCS) ? zynqmp_r5_probe([i], pdev,
> nc) :
> > +-EINVAL;
> > +   dev_dbg(dev, "%s to probe rpu %pOF\n",
> > +   ret ? "Failed" : "Able",
> > +   nc);
> 
> It'd be cleaner to check the child node count before the loop:
> 
>   rpu_nodes = of_get_available_child_count(nc)
>   if ((rpu_mode == PM_RPU_MODE_LOCKSTEP && rpu_nodes != 1) ||
> rpu_nodes > 2)
>   return -EINVAL;
> 
[Ben Levinsky] will do
> > +
> > +   if (ret)
> > +   return ret;
> > +
> > +   i++;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int zynqmp_r5_remoteproc_remove(struct platform_device *pdev)
> > +{
> > +   int i;
> > +
> > +   for (i = 0; i < MAX_RPROCS; i++) {
> > +   struct zynqmp_r5_pdata *pdata = [i];
> > +   struct rproc *rproc;
> > +
> > +   /* only do clean up for pdata with active rpu */
> > +   if (pdata->pnode_id == 0)
> > +   continue;
> 
> This seems like a bit of a hack, resulting from the use of a static
> array for holding the zynqmp_r5_pdata for each rpu.
> 
> Consider allocating zynqmp_r5_pdata in zynqmp_r5_probe, and adding each
> instance to a linked-list at file scope.
>   - memory is only allocated RPUs actually in use
>   - no need for this pnode_id == 0 hack
>   - MAX_RPROCS can be eliminated, just traverse that list in
> remove
>   - No reuse of the pdata across probe/removes, so all of the e.g.
> condtionals below ("if (rproc)") and NULL assignments can be
> eliminated.
> 
[Ben Levinsky] so parts of this I can do.. 
- can make the rpus a static list of ptr's which I think is equivalent
To what you are describing
- can eliminate the pnode_id == 0 hack

For the rproc_del, rproc_free fn calls, these should stay. Just as other 
upstream remoteproc drivers do, this is being done similarly.

For mbox handling, I am mimic'ing upstream ST and TI drivers 
https://github.com/torvalds/linux/blob/v5.9-rc3/drivers/remoteproc/stm32_rproc.c
 
they similarly check if the mbox channel is not NULL, and if so call 
mbox_free_channel. This is similar for Xilinx remoteproc R5 use case as the 
mbox  can be unused in 1 remoteproc node. Also, similar to TI and ST driver, 
https://github.com/torval

[PATCH v15 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

2020-09-21 Thread Ben Levinsky
 prints to not use carriage return, just
  newline
- zynqmp_r5_remoteproc: look up tcm banks via property instead of string
  name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
- device tree binding r5 node to have link to TCMs via
  meta-memory-regions property
- fix device tree binding so no warnings from 'make dt_binding_check'
v12:
- update signed off by so that latest developer name is last
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn
  arg's to reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
v13:
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
v14:
- rebase off v5.9-rc3 kernel
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- in device tree binding, place IPC nodes in RAM in the reserved memory section
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_remoteproc_probe as there is static
  allocation already
- error at probe time if lockstep-mode property not present in device tree
- update commit message as per review
- remove dependency on MAILBOX in makefile as ZYNQMP_IPI_MBOX is present
- remove unused macros
- update comment ordering of zynqmp_r5_pdata to match struct definition
- zynqmp_r5_remoteproc::tcm_mem_release error if pnode id is invalid
- remove obsolete TODOs
- only call zynqmp_r5_remoteproc::zynqmp_r5_probe if the index is valid
- remove uneven dev_dbg/dev_err fn calls
v15:
- change lockstep mode device tree property from acting as
  boolean, to instead being used as, if it is present, then r5 is in lockstep 
mode. otherwise in split.
- add safeguard for if 2 rpu remoteproc instances are provided then err out

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 remoteproc driver

 .../xilinx,zynqmp-r5-remoteproc.yaml  | 120 +++
 drivers/firmware/xilinx/zynqmp.c  |  96 +++
 drivers/remoteproc/Kconfig|   8 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 769 ++
 include/linux/firmware/xlnx-zynqmp.h  |  60 ++
 6 files changed, 1054 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

-- 
2.17.1



[PATCH v15 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

2020-09-21 Thread Ben Levinsky
Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---
 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1



[PATCH v15 3/5] firmware: xilinx: Add RPU configuration APIs

2020-09-21 Thread Ben Levinsky
This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
v11:
- update usage of zynqmp_pm_get_rpu_mode to return rpu mode in enum
- update zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode arguments to 
remove unused args
v12:
- in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
  is only set if no error
- update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn arg's to
  reflect what is expected in the function and the usage in
  zynqmp_r5_remoteproc accordingly
- zynqmp_pm_get_rpu_mode argument zynqmp_pm_get_rpu_mode is
  only set if no error
---
 drivers/firmware/xilinx/zynqmp.c | 61 
 include/linux/firmware/xlnx-zynqmp.h | 18 
 2 files changed, 79 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..b390a00338d0 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,67 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  return by reference value
+ * either split or lockstep
+ *
+ * Return: return 0 on success or error+reason.
+ * if success, then  rpu_mode will be set
+ * to current rpu mode.
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
+{
+   u32 ret_payload[PAYLOAD_ARG_CNT];
+   int ret;
+
+   ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+ IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
+
+   /* only set rpu_mode if no error */
+   if (ret == XST_PM_SUCCESS)
+   *rpu_mode = ret_payload[0];
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @rpu_mode:  Argument 1 to requested IOCTL call. either split or lockstep
+ *
+ * This function is used to set RPU mode to split or
+ * lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
+  0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @tcm_mode:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
+  NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..79aa2fcbcd54 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
+int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
+int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode 
*rpu_mode)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v15 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-21 Thread Ben Levinsky
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations -
* split
* lock-step

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
Signed-off-by: Ben Levinsky 
---
v2:
 - remove domain struct as per review from Mathieu
 v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
 v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
 v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
 v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
 v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
v11:
- use enums instead of u32 where possible in zynqmp_r5_remoteproc
- update usage of zynqmp_pm_set/get_rpu_mode and zynqmp_pm_set_tcm_config
- update prints to not use carriage return, just newline
- look up tcm banks via property in r5 node instead of string name
- print device tree nodes with %pOF instead of %s with node name field
- update tcm release to unmap VA
- handle r5-1 use case
v12:
- update signed off by so that latest developer name is last
- do not cast enums to u32s for zynqmp_pm* functions
v14:
- change zynqmp_r5_remoteproc::rpus and rpu_mode to static
- fix typo
- zynqmp_r5_remoteproc::r5_set_mode set rpu mode from
  property specified in device tree
- use u32 instead of u32* to store in remoteproc memory entry private data
  for pnode_id information
- always call r5_set_mode on probe
- remove alloc of zynqmp_r5_pdata in
  zynqmp_r5_remoteproc::zynqmp_r5_re

[PATCH v15 2/5] firmware: xilinx: Add shutdown/wakeup APIs

2020-09-21 Thread Ben Levinsky
Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
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
v9:
- zynqmp_pm_force_powerdown update arg 'target' to 'node'
- zynqmp_pm_request_wakeup fix code style
v10:
- add types.h to includes for compilation
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 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_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  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_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - 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_wake(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_wake);
+
 /**
  * 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..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,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 +379,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_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(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 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



[PATCH v15 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

2020-09-21 Thread Ben Levinsky
Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 

Signed-off-by: Ben Levinsky 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
v11:
- add property meta-memory-regions to illustrate link
  between r5 and TCM banks
- update so no warnings from 'make dt_binding_check'
v14:
- concerns were raised about the new property meta-memory-regions.
  There is no clear direction so for the moment I kept it in the series
- place IPC nodes in RAM in the reserved memory section
v15:
- change lockstep-mode prop as follows: if present, then RPU cluster is in
  lockstep mode. if not present, cluster is in split mode.
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 120 ++
 1 file changed, 120 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..ce02e425692e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: "xlnx,zynqmp-r5-remoteproc-1.0"
+
+  lockstep-mode:
+description:
+  If this property is present, then the configuration is lock-step.
+  Otherwise RPU is split.
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-region:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication.
+maxItems: 4
+minItems: 4
+  meta-memory-regions:
+description:
+  collection of memories that are not present in the top level memory
+  nodes' mapping. For example, R5s' TCM banks. These banks are needed
+  for R5 firmware meta data such as the R5 firmware's heap and stack
+  pnode-id:
+maxItems: 1
+  mboxes:
+maxItems: 2
+  mbox-names:
+maxItems: 2
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+
+  rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+   no-map;
+   reg = <0x3ed4 0x4000>;
+  };
+  rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+   no-map;
+   reg = <0x3ed44000 0x4000>;
+  };
+  rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+   no-map;
+   reg = <0x3ed48000 0x10>;
+  };
+
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes are label as disabled in
+  * status property
+  */
+ tcm0a: tcm_0a@ffe0 {
+ reg = <0xffe0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ phandle = <0x40>;
+ compatible = "xlnx,tcm";
+ };
+ tcm0b: tcm_1a@ffe2 {
+ reg = <0xffe2 0x1>;
+ pnode-id = <0x10>;
+ no

RE: RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-20 Thread Ben Levinsky
Hi All,

> -Original Message-
> From: Wendy Liang 
> Sent: Friday, September 18, 2020 6:53 PM
> To: Michael Auchter 
> Cc: Ben Levinsky ; punit1.agra...@toshiba.co.jp;
> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5
> remoteproc driver
> 
> HI Michael, Ben, Punit,
> 
> On Fri, Sep 18, 2020 at 12:08 PM Michael Auchter 
> wrote:
> >
> > Hey Ben,
> >
> > On Fri, Sep 18, 2020 at 06:01:19PM +, Ben Levinsky wrote:
> > > Hi Michael, Punit,
> > >
> > > > -Original Message-----
> > > > From: Michael Auchter 
> > > > Sent: Friday, September 18, 2020 9:07 AM
> > > > To: Ben Levinsky 
> > > > Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> linux-
> > > > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > > > Subject: Re: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5
> > > > remoteproc driver
> > > >
> > > > On Thu, Sep 17, 2020 at 10:50:42PM +, Ben Levinsky wrote:
> > > > > In addition to device tree, is there particular linker script you use
> > > > > for your R5 application? For example with OCM? As presently this
> > > > > driver only has DDR and TCM as supported regions to load into
> > > >
> > > > The firmware is being loaded to TCM.
> > > >
> > > > I'm able to use this driver to load and run my firmware on both R5
> > > > cores, but only after I change the incorrect:
> > > >
> > > > rpu_mode = lockstep_mode
> > > >
> > > > assignment to:
> > > >
> > > > rpu_mode = lockstep_mode ? PM_RPU_MODE_LOCKSTEP
> > > >  : PM_RPU_MODE_SPLIT;
> > > There was a point raised by Punit that as "it is possible to set R5 to
> > > operatore in split or lock-step mode dynamically" which is true and
> > > can be done via sysfs and the Xilinx firmware kernel code.
> >
> > I'm not familiar with this, and don't see an obvious way to do this
> > (from looking at drivers/firmware/xilinx/). Can you point me to this
> > code?
> >
[Ben Levinsky] A way to do this, though it seems later comments show it is not 
an implementation to pursue, is use the RPU configuration API and present it 
via sysfs interface a la 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842232/Zynq+UltraScale+MPSoC+Power+Management+-+Linux+Kernel#ZynqUltraScale%EF%BC%8BMPSoCPowerManagement-LinuxKernel-EnableClock
 
> > > A suggestion that might clean up the driver so that the whole
> > > rpu_mode, tcm_mode configuration can be simplified and pulled out of
> > > the driver:
> > > - as Punit suggested, remove the lockstep-mode property
> > > - the zynqmp_remoteproc_r5 driver ONLY loads firmware and does
> start/stop.
> > > - the zynqmp_remoteproc_r5 driver does not configure and memory
> regions or the RPU. Let the Xilinx firmware sysfs interface handle this.
> >
> > I don't think this is a good approach.
[Ben Levinsky] ok, noted. Can keep the configuration but still as wendy said 
just have lockstep property to denote lockstep mode in RPU and otherwise be 
split, for simplicity?
> [Wendy] The TCMs are presented differently in the system depending on
> if RPU is in
> lockstep or split mode.
> 
> Not sure if it is allowed to list TCMs registers properties for both
> split mode and lockstep
> mode in the same device node.
> 
> Even though, driver can have this information in the code, but I feel
> the device tree is a
> better place for this information.
> And also for predefined shared memories, you will need to know the RPU
> op mode ahead,
> so that you can specify which shared memories belong to which RPU.
> 
> To dynamic setup the RPU mode, besides sysfs, setup, if remoteproc can
> support
> device tree overlay, the RPUs can be described with dtbo and loaded at
> runtime.
> 
> Just want to understand the case which needs to set  RPU mode at runtime?
> I think testing can be one case.
> 
[Ben Levinsky] for testing, so far it has been r50/1 split and r5 lockstep
> Best Regards,
> Wendy
> 
> > - How will someone know to configure the RPU mode and TCM mode via
> sysfs?
> > - What happens when someone changes the RPU mode after remoteproc
> has
> >   already booted some firmware on it?
> > - What if the kernel is the one booting the R5, not the user?
> >
> > Split vs

RE: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-18 Thread Ben Levinsky
Hi Michael, Punit,

> -Original Message-
> From: Michael Auchter 
> Sent: Friday, September 18, 2020 9:07 AM
> To: Ben Levinsky 
> Cc: devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5
> remoteproc driver
> 
> On Thu, Sep 17, 2020 at 10:50:42PM +, Ben Levinsky wrote:
> > In addition to device tree, is there particular linker script you use
> > for your R5 application? For example with OCM? As presently this
> > driver only has DDR and TCM as supported regions to load into
> 
> The firmware is being loaded to TCM.
> 
> I'm able to use this driver to load and run my firmware on both R5
> cores, but only after I change the incorrect:
> 
>   rpu_mode = lockstep_mode
> 
> assignment to:
> 
>   rpu_mode = lockstep_mode ? PM_RPU_MODE_LOCKSTEP
>: PM_RPU_MODE_SPLIT;
There was a point raised by Punit that as "it is possible to set R5 to 
operatore in split or lock-step mode dynamically" which is true and can be done 
via sysfs and the Xilinx firmware kernel code. A suggestion that might clean up 
the driver so that the whole rpu_mode, tcm_mode configuration can be simplified 
and pulled out of the driver:
- as Punit suggested, remove the lockstep-mode property
- the zynqmp_remoteproc_r5 driver ONLY loads firmware and does start/stop.
- the zynqmp_remoteproc_r5 driver does not configure and memory regions or the 
RPU. Let the Xilinx firmware sysfs interface handle this.

Few advantages to this:
1. no extra configuration code in the zynqmp r5 remoteproc probe() for either 
R5 in the RPU cluster
2. less state to manage in the remoteproc driver
3. simpler documentation in the device tree binding

Again thank you both for the thoughtful review comments on this
Thanks
Ben


RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-17 Thread Ben Levinsky
> -Original Message-
> From: Ben Levinsky 
> Sent: Thursday, September 17, 2020 3:19 PM
> To: Michael Auchter 
> Cc: punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> Michal Simek ; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiaying Liang
> ; robh...@kernel.org; linux-arm-
> ker...@lists.infradead.org; Jiaying Liang ; Michal Simek
> ; Ed T. Mooring ; Jason Wu
> 
> Subject: RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hi Michael,
> 
> Thanks for the comments,
> 
> > -Original Message-
> > From: Michael Auchter 
> > Sent: Thursday, September 17, 2020 3:11 PM
> > To: Ben Levinsky 
> > Cc: punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> > Michal Simek ; devicet...@vger.kernel.org;
> > mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> > remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiaying Liang
> > ; robh...@kernel.org; linux-arm-
> > ker...@lists.infradead.org; Jiaying Liang ; Michal Simek
> > ; Ed T. Mooring ; Jason Wu
> > 
> > Subject: Re: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> > driver
> >
> > Hey Ben,
> >
> > Split mode is still not functional in this patch series (as was the case
> > with the last few revisions).
> >
> > Before sending out the next revision, can you _please_ ensure you're
> > testing all supported configurations?
> >
> [Ben Levinsky]  I will make sure to update in next revision.
>  As per review, I tested on QEMU and hardware firmware loading in split
> mode on R5 0 split, R5 1 split and R5 lockstep and  was  able to successfully
> load, start and establish IPC links
> 
> That being said, I will update the to reflect the values between the enum for
> rpu operation mode and the documentation in the binding.
> 
> For testing, I can provide a pointer to a publicly available device tree I am
> using if that helps. If not, can you expand on the testing of supported
> configurations?
> 
In addition to device tree, is there particular linker script you use for your 
R5 application? For example with OCM? As presently this driver only has DDR and 
TCM as supported regions to load into 
And I planned to add OCM support if/when the driver gets in.

Thanks,
Ben
> > On Thu, Sep 17, 2020 at 12:43:41PM -0700, Ben Levinsky wrote:
> > > +/**
> > > + * RPU core configuration
> > > + */
> > > +static enum rpu_oper_mode rpu_mode;
> > > +
> >
> > <.. snip ..>
> >
> > > +static int zynqmp_r5_remoteproc_probe(struct platform_device *pdev)
> > > +{
> > > + int ret, i = 0;
> > > + u32 lockstep_mode;
> > > + struct device *dev = >dev;
> > > + struct device_node *nc;
> > > +
> > > + ret = of_property_read_u32(dev->of_node,
> > > +"lockstep-mode",
> > > +_mode);
> > > + if (ret < 0) {
> > > + return ret;
> > > + } else if (lockstep_mode != PM_RPU_MODE_LOCKSTEP &&
> > > + lockstep_mode != PM_RPU_MODE_SPLIT) {
> > > + dev_err(dev,
> > > + "Invalid lockstep-mode %x in %pOF\n",
> > > + lockstep_mode, dev->of_node);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + rpu_mode = lockstep_mode;
> > > +
> > > + dev_dbg(dev, "RPU configuration: %s\n",
> > > + lockstep_mode ? "lockstep" : "split");
> >
> > The binding documents lockstep-mode as:
> >
> > > +  lockstep-mode:
> > > +description:
> > > +  R5 core configuration (split is 0 or lock-step and 1)
> > > +maxItems: 1
> >
> will update this as you note so that lockstep and split mode are accurately
> reflected.
> 
> > (Which needs to be reworded, but it looks like the intent was "split is
> > 0 and lock-step is 1")
> >
> > However, rpu_oper_mode is defined as:
> >
> > > +enum rpu_oper_mode {
> > > +   PM_RPU_MODE_LOCKSTEP = 0,
> > > +   PM_RPU_MODE_SPLIT = 1,
> > > +};
> >
> > so the assignment "rpu_mode = lockstep_mode" is incorrect.
> >
> once the binding is updated, why would this still be incorrect? Assuming the
> documentation is updated, the above line would be ok, right?
> 
> Thank you for the review
> Ben
> 
> > - Michael


RE: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

2020-09-17 Thread Ben Levinsky
Hi Michael,

Thanks for the comments,

> -Original Message-
> From: Michael Auchter 
> Sent: Thursday, September 17, 2020 3:11 PM
> To: Ben Levinsky 
> Cc: punit1.agra...@toshiba.co.jp; Stefano Stabellini ;
> Michal Simek ; devicet...@vger.kernel.org;
> mathieu.poir...@linaro.org; Ed T. Mooring ; linux-
> remotep...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiaying Liang
> ; robh...@kernel.org; linux-arm-
> ker...@lists.infradead.org; Jiaying Liang ; Michal Simek
> ; Ed T. Mooring ; Jason Wu
> 
> Subject: Re: [PATCH v14 5/5] remoteproc: Add initial zynqmp R5 remoteproc
> driver
> 
> Hey Ben,
> 
> Split mode is still not functional in this patch series (as was the case
> with the last few revisions).
> 
> Before sending out the next revision, can you _please_ ensure you're
> testing all supported configurations?
> 
[Ben Levinsky]  I will make sure to update in next revision.
 As per review, I tested on QEMU and hardware firmware loading in split mode on 
R5 0 split, R5 1 split and R5 lockstep and  was  able to successfully load, 
start and establish IPC links

That being said, I will update the to reflect the values between the enum for 
rpu operation mode and the documentation in the binding.

For testing, I can provide a pointer to a publicly available device tree I am 
using if that helps. If not, can you expand on the testing of supported 
configurations?

> On Thu, Sep 17, 2020 at 12:43:41PM -0700, Ben Levinsky wrote:
> > +/**
> > + * RPU core configuration
> > + */
> > +static enum rpu_oper_mode rpu_mode;
> > +
> 
> <.. snip ..>
> 
> > +static int zynqmp_r5_remoteproc_probe(struct platform_device *pdev)
> > +{
> > +   int ret, i = 0;
> > +   u32 lockstep_mode;
> > +   struct device *dev = >dev;
> > +   struct device_node *nc;
> > +
> > +   ret = of_property_read_u32(dev->of_node,
> > +  "lockstep-mode",
> > +  _mode);
> > +   if (ret < 0) {
> > +   return ret;
> > +   } else if (lockstep_mode != PM_RPU_MODE_LOCKSTEP &&
> > +   lockstep_mode != PM_RPU_MODE_SPLIT) {
> > +   dev_err(dev,
> > +   "Invalid lockstep-mode %x in %pOF\n",
> > +   lockstep_mode, dev->of_node);
> > +   return -EINVAL;
> > +   }
> > +
> > +   rpu_mode = lockstep_mode;
> > +
> > +   dev_dbg(dev, "RPU configuration: %s\n",
> > +   lockstep_mode ? "lockstep" : "split");
> 
> The binding documents lockstep-mode as:
> 
> > +  lockstep-mode:
> > +description:
> > +  R5 core configuration (split is 0 or lock-step and 1)
> > +maxItems: 1
> 
will update this as you note so that lockstep and split mode are accurately 
reflected. 

> (Which needs to be reworded, but it looks like the intent was "split is
> 0 and lock-step is 1")
> 
> However, rpu_oper_mode is defined as:
> 
> > +enum rpu_oper_mode {
> > +   PM_RPU_MODE_LOCKSTEP = 0,
> > +   PM_RPU_MODE_SPLIT = 1,
> > +};
> 
> so the assignment "rpu_mode = lockstep_mode" is incorrect.
> 
once the binding is updated, why would this still be incorrect? Assuming the 
documentation is updated, the above line would be ok, right?

Thank you for the review
Ben

> - Michael


  1   2   >